WDIFF

draft-ietf-calsch-ical-00.txt --> draft-ietf-calsch-ical-01.txt

Network Working Group Frank Dawson, Lotus
Internet Draft Derik Stenerson, Microsoft
<draft-ietf-calsch-ical-00.txt> February 3,
<ietf-calsch-ical-01.txt> March 26, 1997
Expires August September 1997

Internet Calendaring and Scheduling Core Object Specification
(iCalendar)

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or made obsolete by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).

Distribution of this document is unlimited.

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
document has been defined to provide the a 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
[RFC1521].
[RFC 2048]. However, the format in this memo is equally applicable
for use outside of a MIME message content type.

[Editor NOTE: This form will be changed to reflect the new MIME
memos in the next draft.]

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 and to-do 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

Dawson/Stenerson 1 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997
or using HTTP. In 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.

Dawson/Stenerson 1 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

This document 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 document is to be known as the iCalendar specification.

This document also includes the format for defining content type
profiles. A content type profile is a document that defines a set of
usage constraints for the iCalendar Object. For example, a profile
might be defined to specify how the iCalendar Object can be used to
provide for a set of interpersonal scheduling messages. Such a
profile 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 calendar component.

Table of Contents

1. Introduction........................................................4
1.1 Definitions ......................................................5
1.1.1
2. Basic Grammar and Conventions.......................................5
3. Definitions.........................................................5
3.1 Alarm ............................................................6
3.2 Busy Time ........................................................6
3.3 Calendar Component ...............................................6
3.4 Calendar Date ....................................................6
3.5 Calendar Object ..................................................6
3.6 Calendar Properties ..............................................6
3.7 Calendar Scale ................................................5
1.1.2 ...................................................6
3.8 Component Properties .............................................6
3.9 Coordinate Universal Time (UTC) ...............................5
1.1.3 ..................................7
3.10 Daylight Saving Time (DST) ....................................5
1.1.4 ......................................7
3.11 Event ...........................................................7
3.12 Free Time .......................................................7
3.13 Gregorian Calendar ............................................5
1.1.5 ..............................................7
3.14 Journal .........................................................7
3.15 Local Time ....................................................5
1.1.6 ......................................................7
3.16 Period ..........................................................8
3.17 Recurrence Rule .................................................8
3.18 Reminder ........................................................8
3.19 Repeating Event or To-do ........................................8
3.20 Standard Time .................................................6
1.1.7 ...................................................8
3.21 Time Zone .....................................................6
2. .......................................................8
3.22 To-do ...........................................................9
4. TEXT/CALENDAR Registration Information..............................6
3. Intended Use........................................................7
3.1 Published specification ..........................................8
3.1.1 Existing Message Header Fields ................................8
3.1.1.1 Content-Type Header Field .................................8
3.1.1.1.1 CHARSET Header Field Parameter .........................8
3.1.1.2 Content-ID Header Field ...................................9
3.1.1.3 Content-Language ..........................................9
3.1.1.4 Message-ID Header Field ...................................9
3.1.1.5 Transfer-Encoding Header Field ............................9
3.1.2 Additional Content Type Parameter .............................9
3.1.2.1 Profile ...................................................9
3.1.3 Content Information..............................9
5. iCalendar Object Specification.....................................11
5.1 Syntax Considerations ................................10
3.1.3.1 Property .................................................10
3.1.3.2 Delimiters ...............................................11
3.1.3.3 Property Value Transfer Encoding .........................12
3.1.3.4 Property Value ...........................................11
5.1.1 Content Lines ................................................12
5.1.2 List and Field Separators ....................................13
5.1.3 Grouping .....................................................14
5.1.4 Multiple Values ..............................................14
5.1.5 Character Set .............................12
3.1.3.5 Property Value ................................................15
5.1.6 Language ..................................13
3.1.3.6 Property Value Data Type .................................13
3.1.3.7 Date and Time ............................................16
3.1.3.8 Time Duration ............................................18 .....................................................15

Dawson/Stenerson 2 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.3.9 Value Location ...........................................19
3.1.3.10

5.1.7 Content Encoding .............................................15
5.1.8 Binary Property Values ..................................19
3.1.3.11 Content ...............................................15
5.1.9 Recurrence Rule Grammar .................................19
3.1.4 Body Delimiter Properties ....................................20
3.1.4.1 Calendar Set ...............................................15
5.1.10 Data Types ..................................................16
5.1.10.1 URL .....................................................16
5.1.10.2 Text ....................................................16
5.1.10.3 Date ....................................................16
5.1.10.4 Time ....................................................17
5.1.10.5 Date-Time ...............................................18
5.1.10.6 Duration ................................................18
5.1.10.7 Period of Time ..........................................19
5.1.10.8 Boolean .................................................19
5.1.10.9 Integer .................................................20
5.1.10.10 Float ..................................................20
5.1.10.11 RFC 822 Address ........................................20
5.1.10.12 UTC Offset .............................................21
5.2 iCalendar Object ..........................................20
3.1.4.2 ................................................21
5.3 Property ........................................................22
5.4 Calendar Components .............................................22
5.4.1 Event Component ..........................................20
3.1.4.3 ..............................................22
5.4.2 To-do Component ..........................................21
3.1.5 ..............................................23
5.4.3 Journal Component ............................................24
5.4.4 Free/Busy Component ..........................................24
5.4.5 Alarm Component ..............................................25
5.4.6 Timezone Component ...........................................26
5.4.7 Calendar Object Properties ...................................21
3.1.5.1 Calendar Content Profile .................................21
3.1.5.2 ..........................................28
5.4.7.1 Calendar Scale ...........................................24
3.1.5.3 Daylight Savings Rule ....................................24
3.1.5.4 ...........................................28
5.4.7.2 Geographic Position ......................................25
3.1.5.5 ......................................29
5.4.7.3 Product Identifier .......................................25
3.1.5.6 Time Zone ................................................26
3.1.5.7 .......................................29
5.4.7.4 Profile ..................................................30
5.4.7.5 Profile Version ..................................................26
3.1.6 Event and To-do ..........................................30
5.4.7.6 Source ...................................................31
5.4.7.7 Source Name ..............................................31
5.4.7.8 Version ..................................................31
5.5 Component Properties .........................26
3.1.6.1 ............................................32
5.5.1.1 Attachment ...............................................26
3.1.6.2 ...............................................32
5.5.1.2 Attendee .................................................27
3.1.6.3 Audio Reminder ...........................................32
3.1.6.4 .................................................32
5.5.1.3 Categories ...............................................33
3.1.6.5 ...............................................34
5.5.1.4 Classification ...........................................34
3.1.6.6 ...........................................35
5.5.1.5 Date/Time Created ........................................35
3.1.6.7
5.5.1.6 Date/Time Completed ......................................35
3.1.6.8 ......................................36
5.5.1.7 Daylight .................................................36
5.5.1.8 Description ..............................................36
3.1.6.9 Display Reminder .........................................36
3.1.6.10
5.5.1.9 Due Date/Time ...........................................37
3.1.6.11 ............................................37
5.5.1.10 Duration ................................................37
3.1.6.12
5.5.1.11 Start Date/Time .........................................38
5.5.1.12 End Date/Time ...........................................37
3.1.6.13 ...........................................38
5.5.1.13 Exception Date/Times ....................................38
3.1.6.14 ....................................39
5.5.1.14 Exception Rule ..........................................38
3.1.6.15 ..........................................39
5.5.1.15 Free/Busy Time ..........................................40
5.5.1.16 Last Modified ...........................................38
3.1.6.16 ...........................................41
5.5.1.17 Location ................................................39
3.1.6.17 Mail Reminder ...........................................39
3.1.6.18 Number Recurrences ......................................40
3.1.6.19 ................................................41
5.5.1.18 Priority ................................................40
3.1.6.20 Procedure Reminder ......................................40
3.1.6.21 ................................................42
5.5.1.19 Related To ..............................................41
3.1.6.22 ..............................................42

Dawson/Stenerson 3 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

5.5.1.20 Recurrence Date/Times ...................................41
3.1.6.23 ...................................43
5.5.1.21 Recurrence Rule .........................................42
3.1.6.24 .........................................44
5.5.1.22 Resources ...............................................42
3.1.6.25 ...............................................49
5.5.1.23 Response Sequence Number ................................43
3.1.6.26 ................................50
5.5.1.24 Sequence Number .........................................44
3.1.6.27 Start Date/Time .........................................44
3.1.6.28 .........................................50
5.5.1.25 Status ..................................................44
3.1.6.29 ..................................................51
5.5.1.26 Summary .................................................46
3.1.6.30 .................................................51
5.5.1.27 Time Transparency .......................................46
3.1.6.31 .......................................52
5.5.1.28 Time Zone Name ..........................................52
5.5.1.29 Time Zone Offset ........................................53
5.5.1.30 Time Zone Transition Time ...............................53
5.5.1.31 Uniform Resource Locator ................................46
3.1.6.32 ................................53
5.5.1.32 Unique Identifier .......................................46
3.1.6.33 .......................................54
5.5.1.33 Non-standard Properties .................................47
3.2 Formal .................................54
5.6 Complete Format Definition ...............................................47
3.3 Basic Recurrence Rule Grammar ...................................53
3.3.1 Daily Rule ...................................................53
3.3.2 Weekly Rule ..................................................54
3.3.3 Monthly Rule .................................................54

Dawson/Stenerson 3 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

3.3.4 Yearly Rule ..................................................55
3.3.5 Grammar ......................................................56
3.3.6 Grammar Glossary .............................................57
3.3.7 Policies .....................................................58
4. ......................................55
6. Registration of Content Type Profiles..............................59
4.1 Profiles..............................65
6.1 Define the profile ..............................................59
4.2 ..............................................65
6.2 Post the profile definition .....................................60
4.3 .....................................66
6.3 Allow a comment period ..........................................60
4.4 ..........................................66
6.4 Submit the profile for approval .................................60
4.5 .................................66
6.5 Profile Change Control ..........................................60
4.6 ..........................................66
6.6 Registration of New Content Type Properties .....................61
4.6.1 ..................................67
6.6.1 Define the property ..........................................61
4.6.2 ..........................................67
6.6.2 Post the Property definition .................................62
4.6.3 .................................68
6.6.3 Allow a comment period .......................................62
4.6.4 .......................................68
6.6.4 Submit the property for approval .............................62
4.7 Content Type .............................68
6.7 Property Change Control ............................62
5. .........................................68
7. File extension.....................................................63
6. extension.....................................................69
8. Macintosh File Type Code...........................................63
7. Bibliography.......................................................63
8. Acknowledgments....................................................64 Code...........................................69
9. Author's Address...................................................64 References.........................................................69
10. Examples..........................................................65 Acknowledgments...................................................70
11. Author's Address..................................................70
12. iCalendar Object Examples.........................................71

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 groupware applications. This specification is intended to
progress the level of interoperability possible between dissimilar
calendaring and scheduling applications. This specification defines a
MIME content type for exchanging electronic calendaring and
scheduling information. The Internet Calendaring and Scheduling Core
Object Specification, or iCalendar Object, iCalendar, allows for the capture and
exchange of information normally stored within a calendaring and
scheduling application; such as a Personal Information Manager or a
Group Scheduling product.

The format is suitable as an exchange format between applications or
systems. The format is defined in terms of a MIME content type. This
will

Dawson/Stenerson 4 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

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 unwired transport such as
infrared might also be used.

The specification also provides for the definition of usage profiles
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 appointments, to-dos and to-dos.
journal entries. The

Dawson/Stenerson 4 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997 usage profiles can be used to define other
calendaring and scheduling operations such a requesting for and
replying with free/busy time data.

The specification also includes a formal grammar for the content type
to aid in the implementation of parsers and to serve as the
definitive reference when ambiguities or questions arise in
interpreting the descriptive prose definition of the specification.

1.1

2. Basic Grammar and Conventions

This document makes use of both a descriptive prose and a more formal
notation for defining the calendaring and scheduling format.

The notation used in this document is the augmented BNF notation of
[RFC 822]. Readers intending on implementing this format defined in
this document should be familiar with this notation in order to
properly interpret the specifications of this document.

All numeric and hexadecimal values used in this document 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 that
is not essential to the building of a conformant implementation
of the specifications of this document. The information is
provided to highlight a particular feature or characteristic of
the specifications.

The format for the iCalendar Object is based on the syntax of the
[MIME DIR] content type. While the iCalendar Object is not a profile
of the [MIME DIR] content type, it does reuse a number of the
elements from the [MIME DIR] specification.

3. Definitions

Date and time time, as well as, calendaring and scheduling terminology is are
used in every day conversations. However, there are precise
definitions of many of these terms that are used by this memo.

1.1.1 Calendar Scale

The particular type

Dawson/Stenerson 5 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

3.1 Alarm

Also called a reminder. An activity that is an asynchronous mechanism
for providing feedback for a pending or past event or to-do.

3.2 Busy Time

A period of time of time on a calendar in general use. For example,
Gregorian, Buddhist Era, Japanese Emperor Era, Chinese Lunar,
Islamic, where there is already
scheduled one or more events or that is otherwise not available for
scheduling.

3.3 Calendar Component

One of a number of entities that may be found within a calendar
object. In particular, a calendar may be composed of calendar
properties and event, to-do, journal, free/busy, time zone or alarm
calendar components. Calendar components are identified by unique
delimiters within a calendar object. Calendar components provide an
organized collection of component properties.

3.4 Calendar Date

A particular day of a calendar year identified by its position within
the year.

3.5 Calendar Object

An entity consisting of an organized collection of calendar
properties and calendar components. The calendar object is identified
by unique delimiters.

3.6 Calendar Properties

Attributes that apply to the calendar object as a whole. For example,
the iCalendar version used to format the calendar object, an
identifier of the product that created the calendar object, the
calendar scale used to represent the calendar information and time
zone information.

3.7 Calendar Scale

The particular type of calendar in general use. For example,
Gregorian, Buddhist Era, Japanese Emperor Era, Chinese Lunar,
Islamic, and Jewish Calendars.

1.1.2

3.8 Component Properties

Attributes that can only appear within one or more calendar
components. For example, the due date can only appear within a to-do
calendar component. The start date and time applies to both the event
and the to-do component.

Dawson/Stenerson 6 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

3.9 Coordinate Universal Time (UTC)

The time scale maintained by the Bureau International de l'Heure
(International Time Bureau) that forms the basis of a coordinated
dissemination of standard frequencies and time signals. UTC is often
incorrectly referred to as GMT.

1.1.3

3.10 Daylight Saving Time (DST)

An adjustment to local to accommodate annual changes in the number of
daylight hours. DST is also known as Advanced Time, Summer Time, or
Legal Time. Daylight saving time adjustments in the southern
hemisphere are opposite to those in the northern hemisphere.

1.1.4

3.11 Event

A calendar component that defines a scheduled activity, minimally
specified by a start and end calendar date and time of day and a
description.

3.12 Free Time

A period of time available on a calendar.

3.13 Gregorian Calendar

A calendar scale in general use beginning in 1582. It was introduced
to correct an error in the Julian Calendar scale. The Gregorian
Calendar scale is based on a solar calendar consisting of common
years made up of 365 days and leap years made up of 366 days; both
divided into 12 sequential months.

Note: Initially, this memo addresses specification of calendar
information in terms of the Gregorian calendar scale.

1.1.5 Local Time

The clock time in

3.14 Journal

A calendar component that defines a collection of information
intended for human presentation and is minimally specified by a
calendar date and one or more descriptions.

3.15 Local Time

The clock time in public use in a locale. Local time is often
referenced by the customary name for the time zone in which it is
located. The relationship between local time and UTC is based on the
offset(s) that are in use for a particular time zone. In general, the
formula is as follows:

local time = UTC + (offset)

Dawson/Stenerson 5 7 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

local

3.16 Period

A duration of time, specified as either a defined length of time = UTC + (offset)

1.1.6 or
by its beginning and end points.

3.17 Recurrence Rule

A notation used to represent repeating occurrences, or the exceptions
to such a repetition of an event or a to-do. The recurrence rule can
also be used in the specification of a time zone description. This
document defines a particular notation used in recurrence rules
within this specification.

3.18 Reminder

See Alarm.

3.19 Repeating Event or To-do

An event or to-do that repeats for one or more additional
occurrences. The recurrence may be defined with discrete dates and
times and/or with a recurrence rule.

3.20 Standard Time

Introduced by Sir Sanford Fleming and others around 1870, standard
time is a scheme for dividing the world into zones where the same
time would be kept. The original proposal was to divide the world
into 24 zones, each zone having a width of 15 degrees of longitude.
The center zone was originally the meridian passing through
Greenwich, England, called Greenwich Mean Time (GMT). The time in the
zones was decremented by one hour per zone going westwards and was
incremented by one hour per zone going eastwards from GMT. Changes
have been made to the original proposal to accommodate political
boundaries. In addition, some countries and regions specify 30 or 45
minute offsets, rather than the full 60 minute offset. Standard time
is also known as Winter Time in some regions.

GMT and UTC are generally equivalent. However, by international
agreement, the GMT term is discouraged in favor of the term UTC for
all general time keeping.

1.1.7

3.21 Time Zone

The particular time zone that a location's time in a particular location is
expressed in. A time zone is unambiguously defined by the set of time
measurement rules determined by the governing body for the given
location. These rules describe at a minimum the base offset from UTC,
often referred to as the Standard Time offset. Optionally, if
Daylight time Savings Time is observed, the rules will specify the
Daylight time Savings Time offset and either a set of rules describing the
transition to and from Daylight time Savings Time or absolute dates
describing the movement in and out of Daylight time. Savings Time. It is
important to note that these rules are not static. Time zones may

Dawson/Stenerson 8 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

also have a local customary name. However, not all time zones have a
special name for their time. The customary names for time zones are
often abbreviated. However, not all time zone abbreviations are
unique. For example, AST may mean Atlantic Standard Time, Alaska
Standard Time, and event even Aleutian Standard Time. Each of these are
different offsets from UTC. Nevertheless, customary names for time
zones are in use in various parts of the world.

3.22 To-do

A calendar component that defines an action item and is minimally
specified by an effective calendar date and time of day, a due
calendar date and time of day, a priority and a description.

4. TEXT/CALENDAR Registration Information

[Editor NOTE: This form will be changed to reflect

The Calendaring and Scheduling Core Object Specification is intended
for use as a MIME content type. However, the revision
to implementation of the
specification is in no way limited solely as a MIME memos when content type.

The following text is intended to register this specification as the respective RFC becomes available.]
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

Required parameters: PROFILE

Dawson/Stenerson 6 Expires August profile

The "profile" parameter is used to convey the scheduling usage to
which the calendaring and scheduling information pertains. It also
is an identifier for the set of properties that the iCalendar
Object will consist of. The parameter is intended to be used as a
guide to 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 profile
definition specifically calls for this behavior. Unless
specifically forbidden by a particular profile definition, a
text/calendar content type may contain any set of properties
permitted by the Calendaring and Scheduling Core Object
Specification.

The value for the "profile" parameter is defined as follows:

profile = component "-" usage

component = "EVENT" / "event" / "TODO" / "todo"
/ "JOURNAL" / "journal" / "FREEBUSY"
/ "freebusy" / x-token / iana-comp

Dawson/Stenerson 9 Expires September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

usage = "REQUEST" / "request" / "REPLY" / "reply"
/ "CANCEL" / "cancel" / "x-token / iana-usage

x-token = <The two characters "X-" or "x-" followed, with
no intervening white space, by any atom, where
atom is from section 3.3 of [RFC 822]>

iana-comp = <A publicly defined extension component,
registered with IANA, as specified by this
document>

iana-usage = <A publicly defined extension usage,
registered with IANA, as specified by this
document>

Optional parameters: CHARSET

Additional required content header fields: CONTENT-ID, MESSAGE-ID charset

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. Note that alternate character sets can be specified
on a per-value basis using the "charset" property parameter defined
in [MIME DIR].

Optional content header fields: CONTENT-LANGUAGE, TRANSFER-ENCODING Any header fields defined by [RFC
2045].

Encoding considerations: This MIME content type does not introduce
any new encoding considerations types beyond those defined in [RFC 2045]. Note
that each property in the content entity may also have an inline
encoding for the body part as a whole (i.e., inline encoding are
performed first, then Content-Transfer-Encoding is applied to the
entire body part). This means that content values may end up
encoded twice.

Security considerations: The calendaring and scheduling information
based on this MIME content type may include references to Uniform
Resource Locators that may be programmed resources. In addition,
this information may contain direct references to executable
programs intended to be used as program-based procedure-based alarms for an event
or to-do. Implementers and users of this specification should be
aware of the network security implications of accepting and parsing
such information.

Interoperability considerations: This MIME content type is intended
to provide interoperability between calendaring and scheduling
products. It is heavily based on the earlier [VCAL] industry
specification.

Intended Usage: COMMON

Published specification: This document.

Person & email address to contact for further information: remainder of this document.

Author/Change controllers:

Dawson/Stenerson 10 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

Frank Dawson
6544 Battleford Drive
Raleigh, NC 27613-3502
919-676-9515 (Telephone)
919-676-9564 (Facsimile)
fdawson@earthlink.net (Internet Mail)

Derik Stenerson
One Microsoft Way
Redmond, WA 98052-6399
206-936-5522 (Telephone)
206-936-7329 (Facsimile)
deriks@microsoft.com (Internet Mail)

3. Intended Use

[Editor NOTE:

5. iCalendar Object Specification

The reference to [RFC 1521] and [MIME-REG] will be
changed to reflect the revision to the MIME memos when following sections define the
respective RFC becomes available.] details of a Calendaring and
Scheduling Core Object Specification. This memo information is meant intended to serve as the basis for registration
be an integral part of a the MIME content type per [RFC1521]. It registration. In
addition, this information may be used independent of such content
registration. In particular, this specification has direct
applicability for use as a calendaring and scheduling exchange format
in file-, memory- or network-based transport mechanisms.

5.1 Syntax Considerations

The content information associated with an iCalendar Object is defined
formatted using a syntax similar to that defined by [MIME DIR]. That
is, the MIME content type
registration from [MIME-REG]. The proposed information consists of one or more CRLF-separated
lines in the following format:

contentline = [group "."] name [";" paramlist] ":" value CRLF
;Folding permitted on content type lines.

group = atom ;As defined in [RFC 822]

name = x-name / iana-name ;An iCalendar attribute/property

x-name = <The two characters "X-" or "x-" followed, with no
intervening white space, by any atom>

iana-name = <A publicly defined name, registered with IANA>

paramlist = parameter / paramlist ";" parameter

parameter = encodingparm
/ valuetypeparm ;If not present => inline value is
"TEXT/CALENDAR". This string would label a media type containing
/ charsetparm
/ languageparm
/ [parmtype "="] parmvalues

encodingparm = "encoding" "=" encodetype

Dawson/Stenerson 7 11 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

calendaring and scheduling information encoded primarily

encodetype = "8bit" ;From [RFC 2045]
/ "7bit" ;From [RFC 2045]
/ "base64" ;From [RFC 2045]
/ "quoted-printable" ;From [RFC 2045]

valuetypeparm = "value" "=" valuetype

valuetype = "url"
/ "text"
/ "date"
/ "time"
/ "date-time"
/ "period"
/ "duration"
/ "boolean"
/ "integer"
/ "float"
/ "rfc822-address"
/ "utc-offset"
/ x-token
/ iana-value

iana-value = <A publicly defined extension value type, registered
with IANA, as text
characters formatted specified by this document>

charsetparm = "charset" "=" charset ;As defined in a manner outlined below. The media type is
useful for conveying inter-personal calendaring and scheduling
information between systems and applications.

A subtype of the standard MIME _TEXT_ media type was chosen [RFC 2047]

languageparm = "language" "=" language ;As defined in [RFC 1766]

parmtype = x-token / iana-ptype

iana-ptype = <A publicly defined extension parameter type,
registered with IANA, as the
form for specified by this content type because it provides a known and reasonable
fallback for legacy systems that are required in an enterprise that
also includes MIME based user agents that support document>

parmvalues = parmvalue / parmvalues "," parmvalue

parmvalue = x-name / iana-pvalue

iana-pvalue = <A publicly defined extension parameter value,
registered with IANA, as specified by this content type.
Legacy systems that do not understand the _TEXT/CALENDAR_ content
type will render these MIME entities document>

value = url / text / date / time/ date-time / period /
/ duration / boolean / integer / float / rfc822-address
/ utc-offset / x-token / iana-value

iana-value = <A publicly defined property value data type,
registered with IANA, as they would _TEXT/PLAIN_
content type. This will provide a minimal level of support for
calendaring and scheduling information defined in legacy systems (i.e., this document>

5.1.1 Content Lines

Individual lines within the
ability to display iCalendar Object are delimited by the text tagged calendaring and scheduling content
information). This
[RFC 822] line break, which is a vital requirement for any mail enabled,
enterprise application; as there are still over 7 million existing
legacy electronic mail user agents at this time.

The calendaring and scheduling media type is specified as an
independent content type in order that it can CRLF sequence (ASCII decimal 13,
followed by ASCII decimal 10). Line should not be conveyed either as a
single MIME message entity or as one MIME entity in a multi-part MIME
message. Additionally, longer than 76
characters, excluding the calendaring and scheduling information may line break.

Dawson/Stenerson 12 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

Long lines of text can be defined in split into a multi-part message containing references to other
MIME body parts holding additional data related to the event, to-do,
or free/busy time information.

3.1 Published specification

The following characteristics are specific to this MIME content type.

3.1.1 Existing Message Header Fields

The MIME Calendar Content Type may utilize any of the message header
fields defined multiple-line representation
using a line "folding" technique. That is, wherever a line split is
desired a CRLF immediately followed by [RFC 822], [RFC 2045], and [RFC 1766]. A number of
these message header fields are especially useful to the iCalendar
Object. These include one LWSP-char must instead be
inserted.

For example the following header fields defined in either
[RFC 822], [RFC 2045], and [RFC 1766].

3.1.1.1 Content-Type Header Field

The [RFC 2045] Content-Type header field line:

DESCRIPTION:This is used to identify the
iCalendar Object. a long description that exists on a long line.

Can be represented as:

DESCRIPTION:This is a long description
that exists on a long line.

The value process of moving from this folded multiple-line representation
to its single line representation is called "unfolding". Unfolding is
accomplished by removing the CRLF immediately followed by a LWSP-
char.

An intentional formatted text line break in a property value must
also be _text/calendar_
in order to correspond to the media type defined specified by this document.
This header field a (RFC 822) line break, which is required for MIME entities conforming to this
content type.

3.1.1.1.1 CHARSET Header Field Parameter

The [RFC 2045] CHARSET Content-Type header field parameter a CRLF
sequence. However, since the CRLF sequence is used to
identify delimit a line,
property values with imbedded formatted line breaks (i.e., hard line
breaks) must be encoded using an alternate character set to encoding of either quoted-
printable or base64, as defined in [RFC 2045].

The quoted-printable encoding of the default US-ASCII used multiple lines of formatted text
are separated with a quoted-printable CRLF sequence of "=0D" followed
by "=0A" followed by a Quoted-Printable soft line break sequence of
"=". Quoted-printable lines of text must also be limited to less than
76 characters. The 76 characters does not include the iCalendar Object. CRLF [RFC 822]
line break sequence. For example a multiple line DESCRIPTION value
of:

Project XYZ Final Review
Conference Room - 3B
Come Prepared.

Would be represented in a Quoted-Printable encoding as:

DESCRIPTION; QUOTED-PRINTABLE:Project XYZ Final Review=0D=0A=
Conference Room - 3B=0D=0A=
Come Prepared.

White space characters (i.e., HTAB and SPACE characters, ASCII
decimal 9 and 32) to the left of a "value" may freely surround any
symbol. This header field means that if a "value" begins with a white space
character, it must be encoded using either the base64 or quoted-
printable encoding methods.

5.1.2 List and Field Separators

Where a property parameter is optional for
MIME entities conforming to this content type. value consists of a list of values, each
value must be separated by a COMMA character (ASCII decimal 44). A

Dawson/Stenerson 8 13 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.1.2 Content-ID Header Field

The [RFC 2045] Content-ID header field is used by the iCalendar
Object to provide

COMMA character in a persistent, globally unique identifier for property parameter value must be escaped with a MIME
Calendar Object within
BACKSLASH character (ASCII decimal 92).

Structured property values must have their components separated by a MIME message entity. This header field is
required for multi-part MIME entities containing an iCalendar Object
that conforms to this content type.
SEMICOLON character (ASCII decimal 59). In the event that the iCalendar
Object is transported in a MIME message containing addition, lists of
property parameters must be separated by a single body,
then SEMICOLON character (ASCII
decimal 59). A SEMICOLON character in a property value or property
parameter value must be escaped with a BACKSLASH character (ASCII
decimal 92).

For example, in the Message-ID header field is required.

3.1.1.3 Content-Language

The [RFC 1766] Content-Language header field following properties a SEMICOLON is used to provide an
alternate default language for the MIME Calendar Object. The default
language is _en-US_. This header field
separate property parameters and property value fields. A COMMA is optional for MIME entities
conforming
used to this content type.

3.1.1.4 Message-ID Header Field separate values.

ATTENDEE;RSVP=YES;ROLE=ATTENDEE:"J.Smith" <jsmith@host.com)
RDATE;VALUE=DATE:19970304,19970504,19970704,19970904

5.1.3 Grouping

The [RFC 2045] Message-ID header field group construct is used by the iCalendar
Object to provide a persistent, globally unique identifier for a MIME
message containing a single body part consisting of a iCalendar
Object. This header field group related properties together. The
group name is required for a single body part MIME
message conforming syntactic convention used to this content type. In indicate that all
property names prefaced with the event same group name should be processed
together when displayed by an application. It has no other
significance. Implementations that do not understand or support
grouping may simply strip off any text before the
iCalendar Object is transported PERIOD character
(ASCII decimal 46) and present the property and value as normal.

The following provides an example of property grouping. The first
start, end and busy time are grouped together with a body part within a multi-part
MIME message, the Content-ID header field must be specified. label "GROUPA".
The
Message-ID header field is used to unambiguously refer to second start, end and busy time are grouped together with a label
"GROUPB".

GROUPA.DTSTART:19970101T000000-0500
GROUPA.DTEND:19970101T235959-0500
GROUPA.BUSYTIME;VALUE=PERIOD-START:19970101T000000-0500/PT8H30M,
19970101T100000-0500/PT2H,19970101T150000-0500/PT20H59M59S
GROUPB.DTSTART:19970102T000000-0500
GROUPB.DTEND:19970102T235959-0500
GROUPB.BUSYTIME;VALUE=PERIOD-START=19970102T000000-5000/PT10H,
19970102T130000-0500/PT6H

5.1.4 Multiple Values

Each attribute or property defined in the iCalendar Object within a MIME entity.

3.1.1.5 Transfer-Encoding Header Field may have
multiple values, if allowed in the definition of the specific
property. The [RFC 2045] Transfer-Encoding header field general rule for encoding multi-valued items is used to provide an
alternate transfer encoding for the iCalendar Object. The default
transfer encoding is _7BIT_. This header field is required for
simply create a MIME
entity conforming to this new content type when any other line for each value; including the
property name. However, it should be noted that some properties
support encoding is
used multiple values in the iCalendar Object.

3.1.2 Additional Content Type Parameter

In addition to the existing content type parameters defined a single property by [RFC
2045] and [RFC 1766], this document defines an additional content
type separating
the values with a COMMA (ASCII decimal 44).

Dawson/Stenerson 14 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

5.1.5 Character Set

The "charset" property parameter should be used to identify character
sets other than "US-ASCII". The "charset" property parameter can be
used by to change the iCalendar Object.

3.1.2.1 Profile default character set on a per-value basis. The MIME Calendar Object defines
value of the Profile content type parameter.
This charset property parameter is any IANA registered
character set.

Note: For transport in a MIME entity, the "charset" Content-Type
parameter may be used to specify a usage profile set the default character set for the iCalendar
Object.
entire body part.

5.1.6 Language

The value of this "language" property parameter consists of a type and a subtype
value pair. The type value is should be used to specify either a EVENT, TODO,
or FREE-BUSY type of MIME Calendar Object profile. identify data in
alternate languages. The default language is "us-EN". The subtype value of
the language property parameter is that defined in [RFC 1766].

Note: For transport in a MIME entity, the Content-Language
header field may be used to specify the scheduling operation being conveyed by set the
profile type. For example, default language for the EVENT and TODO type values might have
a subtype value of REQUEST,
entire body part.

5.1.7 Content Encoding

The "encoding property parameter should be used to convey an event or to-do request
message, REPLY, to convey an event or to-do reply message, MODIFY, to

Dawson/Stenerson 9 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

convey an event or to-do modification message, CANCEL, to convey an
event or to-do cancellation message, DELEGATE, to convey specify an event or
to-do delegation message; or the BUSYFREE type value might have
alternate encoding for a
subtype value. If the value of REQUEST, to convey contains a free-busy time request message
, <CR>
character (ASCII decimal 10) or REPLY, to convey a free-busy time data message. The parameter
value <LF> character (ASCII decimal 13), it
must be encoded using either base64 or quoted-printable, since
<CR><LF> is defined by used to separate lines in the following BNF:

profile := ((_EVENT_ / _ _)
TODO _-_ type1) / (_FREEBUSY_ _-_ type2)

type1 := <any IANA values defined by an iCalendar Object usage
profile or an _X-_ type itself.

5.1.8 Binary Content

There is no support for inline encoding of non-standard value>

type2 := <any IANA value defined by binary information in an
iCalendar Object usage
profile or an _X-_ type of non-standard value>

The following Object. Binary information is an example associated with the iCalendar
Object through the use of this content type parameter for a
profile that specifies an event request message, such uniform resource locator (URL) reference
to the binary information.

5.1.9 Recurrence Set

Recurring events and to-dos are supported by this specification. The
recurrence within the iCalendar Object may be specified as in a request
for either a meeting
list of discrete date and time values or appointment:

CONTENT-TYPE:TEXT/CALENDAR;PROFILE=EVENT-REQUEST as a recurrence rule. The following
full recurrence set is an example generated by considering the initial DTSTART
along with the RRULE, RDATE, EXDATE and EXRULE properties contained
within the iCalendar object. Multiple instances of this content type parameter for a
profile that specifies a to-do delegation message, such as delegating
a task the RRULE and
EXRULE properties may also be specified to another individual:

CONTENT-TYPE:TEXT/CALENDAR;PROFILE=TODO-DELEGATE define more sophisticated
recurrence sets. The following final recurrence set is an example generated by gathering
all of this content type parameter for a
profile that specifies a free-busy time request, such as when
searching for a free time for a meeting:

CONTENT-TYPE:TEXT/CALENDAR;PROFILE=FREEBUSY-REQUEST

This content type parameter is required for MIME entities conforming
to this content type. Other memos are expected to address specific
usage profiles and define values for this property.

3.1.3 Content Syntax Considerations

The following general considerations are specific to the syntax used
to format the text start date-times generated by any of the body information for this content type.

3.1.3.1 Property

A property is specified RRULE
and RDATE properties, and excluding any start date and times which
fall within the definition union of an individual attribute describing an
event or a to-do associated with the MIME Calendar Object. A property
takes the following form:

property := propname *(_;_ propparm) _:_ propvalue

as shown in the following example:

DTSTART:19960415T083000-05:00 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).

Dawson/Stenerson 10 15 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

A property takes the form of one or more lines of text.

The
specification of property names and property parameters recurrence rule used in the iCalendar Object is case
insensitive. defined in the
RRULE component property.

5.1.10 Data Types

The "value" property name can be one of a set of pre-defined or
non-standard strings. The parameter is an optional property name must appear as the first
characters on a line. In the previous example, _DTSTART_ parameter. It
is used to identify the name data type and format of the Start Date/Time property. Property values property value.
The following data types are specified as
strings. In used by the previous example, _19960415T083000-05:00_ is the
formatted value for the Start Date/Time property.

The property parameter expressions are specified as either a
name=value or a value string. iCalendar Object.

5.1.10.1 URL

The parameter value string can be
specified alone in those cases where the value "url" data type is unambiguous. For
example a complete property parameter specification might be:

DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Don't forget used to order Girl=
Scout cookies from Stacey today!

A valid short version identify values that contain a uniform
resource locator (URL) type of reference to the same property parameter specification value. This
data type might be:

DESCRIPTION;QUOTED-PRINTABLE:Don't forget be used to order Girl=
Scout cookies from Stacey today!

3.1.3.2 Delimiters

Individual lines within the iCalendar Object body reference binary information, for values
that are delimited by large, or otherwise undesirable to include directly in the [RFC 822] line break, which
iCalendar Object. The data type is a CRLF sequence (ASCII decimal 13,
followed defined by ASCII decimal 10). Long lines of text can be split into a
multiple-line representation using the RFC 822 _folding_ technique.
That is, wherever there may be linear white space (NOT simply LWSP-
chars), a CRLF immediately followed following notation:

url = <As defined by at least one LWSP-char [RFC 1738]>

Any IANA registered URL type may
instead be inserted. used. These include, but are not
limited to, those for FTP and HTTP protocols, file access, content
identifier and message identifier.

For example example, the line:

DESCRIPTION:This following is an URL for a long description that exists on a long line.

Can be represented as:

DESCRIPTION:This local file:

file:///my-report.txt

5.1.10.2 Text

The "text" data type is a long description used to identify values that exists on a long line. contain human
readable text. The process of moving from this folded multiple-line representation
of a property definition to its single line representation character set and language in which the text is called
_unfolding_. Unfolding
represented is accomplished by regarding CRLF immediately
followed controlled by a LWSP-char as equivalent to the LWSP-char.

It is recommended that folding be limited to higher-level syntactic
breaks in structured components of the property definition.

A formatted text line break in a charset and language property value, must also be
specified by a (RFC 822) line break, which
parameters. The data type is a CRLF sequence.
However, since defined by the CRLF sequence following notation:

CHAR = <Any character in the selected character set>

text = <Any CHAR, including bare CR & bare LF but not
including CRLF>

5.1.10.3 Date

The "date" data type is used to delimit a line, property identify values with formatted line breaks (i.e., multiple lines) must be
encoded using an alternate encoding of either Quoted-Printable or
Base64, that contain a
calendar date. The format is expressed as the [ISO 8601] complete
representation, basic format for a calendar date. The text 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. The data type is defined in [RFC 2045]. by the following
notation:

DIGIT =<any ASCII decimal digit> ;0-9

date-fullyear = 4DIGIT
date-month = 2DIGIT ;01-12
date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31

Dawson/Stenerson 11 16 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

;based on month/year
full-date = date-fullyear date-month date-mday

date = fulldate *["," fulldate]

For example, in the Quoted-Printable encoding following represents July 14, 1997:

19970714

5.1.10.4 Time

The "time" data type is used to identify values that contain a time
of day. The format is expressed as the multiple lines [ISO 8601] complete
representation, basic format for a time of
formatted day. The text are separated with format
consists of a Quoted-Printable CRLF sequence two-digit 24-hour of
_=0D_ followed by _=0A_ followed the day, two-digit minute in the
hour, and two-digit seconds in the minute. If seconds of the minute
are not supported by an implementation, then a Quoted-Printable soft line
break sequence of _=_. Quoted-Printable lines value of text must also "00" should
be
limited to less than 76 characters. The 76 characters does not
include specified for the CRLF [RFC 822] line break sequence. For example a
multiple line DESCRIPTION value of:

Project XYZ Final Review
Conference Room - 3B
Come Prepared.

Would be represented in a Quoted-Printable encoding as:

DESCRIPTION; QUOTED-PRINTABLE:Project XYZ Final Review=0D=0A=
Conference Room - 3B=0D=0A=
Come Prepared.

Property parameter sub-strings seconds component. Fractions of an hour, minute
or second are delimited by a field delimiter,
specified not supported by the Semi-colon character (ASCII decimal 59). A Semi-
colon character in a property parameter value must be escaped this format. This format is used to
represent local time, local time with UTC offset and UTC time. UTC
time is identified by a
Backslash LATIN CAPITAL LETTER Z suffix character
(ASCII decimal 92).

Compound property values are delimited by 90), the UTC designator, appended to the time. The
local time with UTC offset is expressed as a field delimiter,
specified by local time, suffixed
with the signed offset from UTC. The UTC offset is express as the Semi-colon 2-
digit hours and 2-digit minutes difference from UTC. It is expressed
as positive, with an optional leading PLUS SIGN character (ASCII
decimal 59). A Semi-
colon character in a component 43), if the local time is ahead of UTC. It is expressed as a compound property value must be
escaped
negative, with a Backslash leading HYPEN-MINUS character (ASCII decimal 92).

3.1.3.3 Property Value Transfer Encoding

The default transfer encoding for 45), if
the iCalendar Object local time is _7BIT_. behind UTC. Local time has neither the UTC
designator nor the UTC offset suffix text. The
default transfer encoding can be overridden for an individual
property value data type is defined
by using the _ENCODING_ following notation:

DIGIT =<any ASCII decimal digit> ;0-9

time-hour = 2DIGIT ;00-24
time-minute = 2DIGIT ;00-60
time-second = 2DIGIT ;00-59
time-numzone = ("+" / "-") time-hour time-minute
time-zone = "Z" / time-numzone
full-time = time-hour time-minute time-second [time-zone]

time = fulltime *["," fulltime]

For example, the following represents 8:30 AM in New York, five hours
behind UTC, in local time and local time with UTC offset. In
addition, 1:30 PM in UTC is illustrated:

083000
083000-0500
133000Z

There are cases when a floating time is intended within a property parameter. This
parameter value can be either _7BIT_, _BASE64_, _QUOTED-PRINTABLE_,
or _8BIT_. This parameter may be used on any property.

The MIME TRANSFER-ENCODING header field can be used to specify a
default transfer encoding other than 7BIT (e.g., 8BIT).

3.1.3.4 Property Value Character Set

The default character set for a iCalendar Object is ASCII. The
default character set can be overridden for
value. For example, an individual property
value by using the _CHARSET_ property parameter. This property
parameter may be used on any property. However, the use of this
parameter on some properties event may not make sense.

Any character set registered with the Internet Assigned Numbers
Authority (IANA) can be specified by this property parameter. For
example, ISO 8859-8 or the Latin/Hebrew character set is specified
by:

DESCRIPTION;CHARSET=ISO-8859-8:... defined that indicates that an

Dawson/Stenerson 12 17 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

The MIME CHARSET parameter on the CONTENT-TYPE header field can

individual will be
used busy from 11:00 AM to specify 1:00 PM every day. In these
cases, a default character set other than ASCII (e.g., UTF-
8).

3.1.3.5 Property Value Language local time may be specified. The default language for a recipient of an iCalendar
Object is _en-US_ (US English).
The default language can be overridden for an individual with a property value by using the _LANGUAGE_ property parameter. The values for this
property are a string consistent with RFC 1766, Tags for the
Identification consisting of Languages. This property parameter may be used on a local time, without any property. However,
relative time zone information, should interpret the use of this parameter on some properties,
such value as PHOTO, LOGO, SOUND, TEL, may not make sense. Canadian French
would be specified by this property parameter by the following:

SUMMARY;LANGUAGE=fr-CA:...

The MIME LANGUAGE parameter on the CONTENT-TYPE header field can be
used to specify a default language other than US English (e.g., fr-
CA).

3.1.3.6 Property Value Data Type

In order being
fixed to more fully specify the semantics of this content type recipient's locale and
to facilitate its automated processing, the specification of each time zone. In most cases, a fixed
time is desired. To properly communicate a fixed time in a property defined by the iCalendar Object identifies the valid
value, either UTC, local time with UTC offset, or local time with a
time zone calendar component must be specified.

5.1.10.5 Date-Time

The "date-time" data
types type is used to identify values that contain a
precise calendar date and time of day. The format is expressed as the default data type
[ISO 8601] complete representation, basic format for the property value. In addition,
within an instance a calendar date
and time of this content type day. The text format is a property may explicitly
convey concatenation of the data type information through "date",
followed by the DATATYPE property
parameter. LATIN CAPITAL LETTER T character (ASCII decimal 84)
time designator, followed by the "time" format defined above. The STRING
data type for the DESCRIPTION property would be
specified is defined by the following:

DESCRIPTION;DATATYPE=STRING:Weekly Staff Meeting

If the DATATYPE property parameter is not following notation:

date-time = date "T" time ;As specified on a property,
then above in date and time

The following represents July 14, 1997, at 1:30 PM in UTC and the default
equivalent time in New York (five hours behind UTC), expressed as a
local time and local time with UTC offset:

19970714T133000Z
19970714T083000
19970714T083000-0500

5.1.10.6 Duration

The "duration" data type for that property is assumed. Usage
profiles for this content type that introduce new used to identify properties must
specify that contain
a duration of time. The format is expressed as the default data type [ISO 8601] basic
format for each newly defined property. the duration of time. The format can represent durations
in terms of years, months, days, hours, minutes, and seconds. The
data types used within this content type definition include the
following:

Property Data Description
Type

AALARM Indicates an
audio alarm
value, as
specified is defined by
this
document.

Dawson/Stenerson 13 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

BOOLEAN Indicates a
Boolean value
string of
either TRUE
or FALSE.

CID Indicates a
string
identifier
value for the
content
identifier of
another MIME
entity within the current
message.

DALARM Indicates a
display alarm
value, as
specified by
this
document.

DATE-TIME Indicates an
ISO 8601
formatted
date/time
string value.

DST-RULE Indicates a
daylight
saving time
rule value as
specified in
this
document.

D-T-LIST Indicates following notation:

DIGIT =<any ASCII decimal digit> ;0-9

dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)

dur-week = 1*DIGIT "W"
dur-day = 1*DIGIT "D"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]

duration = "P" (dur-date / dur-time / dur-week)

For example, a
list of ISO
8601
formatted
date/time
string
values.

DURATION Indicates an
ISO 8601
formatted duration or
period of
time value. 10 years, 3 months, 15 days, 5 hours, 30
minutes and 20 seconds would be:

Dawson/Stenerson 14 18 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

FLOAT Indicates a
string
representatio
n

P10Y3M15DT5H30M20S

5.1.10.7 Period of Time

The "period" data type is used to identify values that contain a
floating
point value.

FLOAT-LIST Indicates a
list of
string
representatio
ns
precise period of
floating
point values.

INTEGER Indicates a
numeric
string
representatio
n time. There are two forms of an
integer
value.

INTEGER-LIST Indicates a
list period of
numeric
string
representatio
ns time.

A period of an
integer
value.

MALARM Indicates a
mail alarm
value, as
specified time may be identified by
this
document.

MID Indicates a
string
identifier
value it start and its end. This
format is expressed as the [ISO 8601] complete representation, basic
format for an
external
message.

PALARM Indicates "date-time" start of the period, followed by a
procedure
alarm value,
as specified SOLIDUS
character (ASCII decimal 47), followed by this
document.

Dawson/Stenerson 15 Expires August the "date-time" of the end
of the period. For example, the period starting at 10 AM in Seattle
(eight hours behind UTC) on January 1, 1997

Internet Draft C&S Core Object Specification February 3, and ending at 11 PM in
Seattle on January 1, 1997

RFC822- Indicates a
ADDRESS RFC 822
formatted
address
specification
string value.

RRULE Indicates would be:

19970101T100000-0800/19970101T230000-0800

A period of time may also be defined by a
recurrence
rule grammar
string value
as specified
in this
document.

STRING Indicates start and a
text string
value in duration of
time. The format is expressed as the
current
character
set.

STRING-LIST Indicates [ISO 8601] complete
representation, basic format for the "date-time" start of the period,
followed by a
list SOLIDUS character (ASCII decimal 47), followed by the
[ISO 8601] basic format for "duration" of text
string values the period. For example,
the period start at 10 AM in Seattle (eight hours behind UTC) on
January 1, 1997 and lasting 5 hours and 30 minutes would be:

19970101T100000-0800/P5H30M

The data type is defined by the
current
character
set.

TIME-OFFSET Indicates an
ISO following notation:

period-explicit = date-time "/" date-time
;ISO 8601
formatted complete representation basic format for a period of time offset
value

URL Indicates
;consisting of a
RFC 1738
formatted
Uniform
Resource
Locator
string. start and end. The property values consisting start must be before the end.

period-start = date-time "/" duration
;ISO 8601 complete representation basic format for a period of lists time
;consisting of a particular data type
(i.e., STRING-LIST) are semi-colon separated string of list items.

3.1.3.7 Date start and Time duration of time.

period = period-explicit / period-start

5.1.10.8 Boolean

The date and time values for all iCalendar Object "boolean" data type is used to identify properties are
formatted as that contain
either a string consistent with "true" or a "false" boolean value. These values are case
insensitive. The data type is defined by the ISO 8601 representation for following notation:

boolean = "TRUE" / "FALSE"

For example, any of the following are equivalent:

TRUE
true
TrUe

Dawson/Stenerson 16 19 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

combinations of dates and times. Either the basic or extended format
is allowed.

5.1.10.9 Integer

The use of UTC, rather than local time, should be "integer" data type is used
when ever possible in order to avoid time zone ambiguities. Where
local time identify properties that contain a
signed integer value. The valid range for "integer" is -2147483648 to
2147483647. If the sign is not specified, then the inclusion of value is assumed
to be positive. If the UTC offset should also property permits, multiple "integer" values
may be included to avoid time zone ambiguities. specified using a COMMA character (ASCII decimal 44) separator
character. The format for data type is defined by the
complete, representation of following notation:

DIGIT =<any ASCII decimal digit> ;0-9

integer = ["+" / "-"] *DIGIT

For example:

1234567890
-1234567890
+1234567890
432109876

5.1.10.10 Float

The "float" data type is used to identify properties that contain a date and time
real value number value. If the property permits, multiple "float"
values may be specified using a COMMA character (ASCII decimal 44)
separator character. The data type is represented defined by the following ABNF:

date-time
notation:

DIGIT =<any ASCII decimal digit> ;0-9

float = (date ["+" / time "-"] *DIGIT ["." *DIGIT]

For example:

1000000.0000001
1.333
-3.14

5.1.10.11 RFC 822 Address

The "rfc822-address" data type is used to identify properties that
contain a calendar address. The phrase component of the address may
be used to match an unknown address with an otherwise known
individual, group, or resource. The data type is as defined by the
following notation:

rfc822-address = addr-spec / (date _T_ time))

date [phrase] "<" addr-spec ">"

addr-spec = year month day
year local-part "@" domain ;RFC 822 address
local-part = <four digits representing the century and year>
month WORD *("." WORD)
domain = [_-_] <digits representing the month in the year>
day domain-ref *("." domain-ref)
domain-ref = [_-_] <digits representing the day of the month>

time ATOM

Dawson/Stenerson 20 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

phrase = hour minute second [fraction](utc-sign 1*WORD
WORD = ATOM / utc-offset)
hour quoted-string
quoted-string = <digits representing a period of time of 60 minutes>
minute <"> *(qtext/quoted-pair) <"> ; Regular qtext or
; quoted chars.
qtext = [_:_] <digits representing a period of time of 60
seconds>
second <any CHAR excepting <">, ; => may be folded
"\" & CR, and including linear-white-space>
quoted-pair ="\" CHAR ; may quote any char
CHAR = [_:_] <digits representing <any a basic measurement unit
of time in character from the International System of Units as defined
in ISO 31-1>
fraction = _,_ <digits representing fraction of a second>
utc-sign selected character set>
ATOM = _Z_
utc-offset = [_+_ / _-_] hour [_:_] minute
;_+_ if offset is after UTC 1*<any CHAR except specials, SPACE and _-_ if offset CTLs>

5.1.10.12 UTC Offset

The "utc -offset" data type is before used to identify properties that
contain an offset from UTC to local time. The basic complete representation does not include the _-_ date
separator nor data type is defined by
the _:_ following notation:

utc-offset = time-numzone ;As defined above in time separator. The extended complete
representation does include the separators. data type

For example, 8:30 AM on April 15, 1996 local time EST would be
written as:

19960415T083000-05:00

And the same time in following are UTC based time would be written as:

19960415T133000Z

The same date offsets for New York (five hours
behind UTC) and time represented in the extended completed
representation would be written as:

1996-04-15T08:30:00-05:00

And the same time in UTC based time would be written as:

1996-04-15T13:30:00Z

Where a value needs to specify a sequence Geneva (one hour ahead of date UTC):

-0500 ;New York
+0100 ;Geneva

5.2 iCalendar Object

The Calendaring and time values,
then the property value Scheduling Core Object is a string made up collection of a list
calendaring and scheduling information. Typically, this information
will consist of date a single iCalendar Object. However, multiple
iCalendar Objects may be sequentially, grouped together. The first
line and
time values, separated by last line of the field separator, iCalendar Object must contain a Semi-Colon (ASCII
decimal 59). For example: pair of
iCalendar Object delimiter strings. The syntax for a vCalendar Object
is as follows:

icalobject = "BEGIN" ":" "VCALENDAR" CRLF
icalbody
"END" ":" "VCALENDAR" CRLF [icalobject]

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:19970714T120000-0500
DTEND:19970714T235959-0500
DESCRIPTION:Bastile Day Party
END:VEVENT
END:VCALENDAR

Dawson/Stenerson 17 21 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

19960101T090000Z;19960201T090000Z;19960301T090000Z;...

3.1.3.8 Time Duration

The values for time duration or periods of time for all iCalendar
Object properties are formatted as a string consistent with the ISO
8601 representation for duration of time.

5.3 Property

A given duration of a
period of time property is represented by a character string consisting of the
designator _P_, optionally including the number of years followed by
the designator _Y_, optionally including the number definition of months
followed by the designator _M_, optionally including an individual attribute describing a
calendar property or a calendar component. A property takes the number of
weeks followed
following form:

property = [group "."] propname [";" parmlist] ":" value CRLF

propname = <any properties defined in this document>
/ iana-prop / x-token

x-token = <The two characters "X-" or "x-" followed, with no
intervening white space, by the designator _W_, optionally including the number
of days followed any atom>

iana-prop = <A publicly defined extension property, registered
with IANA, as specified by the designator _D_. this document>

The sequence can also contain following is an example of a time component preceded by the designator _T_, optionally including
the number property:

DTSTART:19960415T083000-05:00

This document places no imposed ordering of hours followed by the designator _H_, optionally
including properties within an
iCalendar Object.

Property names, parameter names and parameter values (i.e.,
everything to the number left of minutes followed by the designator _M_,
optionally including ":" on a line) are case insensitive.
For example, the number of seconds followed by property name "DUE" is the designator
_S_. same as "due" and "Due".

5.4 Calendar Components

The following ABNF describes body of the representation iCalendar Object consists of ISO 8601
periods a sequence of time:

duration = _P_ (yr-period / tm-period / (yr-period tm-period))
;Duration needs to include at least calendar
properties and one component of year or
;time periods

yr-period = [yr-parm] [mo-parm] / wk-parm
yr-parm = _Y_ <digits representing more calendar components. The calendar
properties are attributes that apply to the number calendar as a whole. The
calendar components are collections of years>
mo-parm = _M_ <digits representing properties that with a
particular calendar semantic. For example, the number calendar component may
specify a an event, a to-do, journal entry, time zone information, or
free/busy time information, or alarm.

The body of months>
wk-parm = _W_ <digits representing the number of weeks>

tm-period = _T_ [hr-parm] [mn-parm] [sc-parm]
hr-parm = _H_ <digits representing iCalenar Object is defined by the number of hours>
mn-parm following notation:

icalbody = _M_ <digits representing the number of minutes>
sc-parm calprops 1*component

calprops = _S_ <digits representing the number of seconds>

For example:

P6W

represents a period of six weeks;

PT15M

represents a period of 15 minutes;

PT1H30M

represents [calscale] [geo] prodid [profile] [profile-version]
[source] [name] version

component = 1*(eventc / todoc / journalc / freebusyc /
/ timezonec)

5.4.1 Event Component

An Event Calendar Component is a period grouping of 1 hour component properties and thirty minutes; or

P2Y10M15DT10H30M20S

represents
an optional alarm calendar component that represent a period scheduled
amount of 2 years, 10 months, 15 days, 10 hours, 30
minutes, and 20 seconds. time on a calendar. For example, it may be an activity;

Dawson/Stenerson 18 22 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.3.9 Value Location

The default location of the property values is inline with the
property. However, for some properties,

such as those that specify
multimedia values, it is more efficient in a MIME message one-hour, department meeting from 8:00 AM to organize 9:00 AM,
tomorrow.

An Event Component is defined by the property value as a separate MIME entity. following notation:

eventc = "BEGIN" ":" "VEVENT" CRLF
*eventprop *alarmc
"END" ":" "VEVENT" CRLF

eventprop = *attach *attendee *categories [class]
/ [created] description dtend dtstart *exdate
/ *exrule *last-mod [location] [priority]
/ *related *resources *rdate *rrule
/ [resp-seq] / [seq] [status] [summary] [transp]
/ [uid] *url

The property parameter
_VALUE_ Event Component can not be specified to override the _INLINE_ location of the
property value. In the case of the iCalendar Object being transported nested within a MIME email message, the property value can another Calendar
Component. Event components may be specified as
being located in related to each other or to a separate MIME entity with the _CONTENT-ID_ value; To-
do or _CID_ for shorthand. In this case, Journal Calendar Component with the property value RELATED-TO property.

The following is an example of the
Content-ID for the MIME entity within the multi-part message Event Calendar Component:

BEGIN:VEVENT
DTSTART:19970903T083000-0800
DTEND:19970903T110000-0500
DESCRIPTION:Annual Employee Review
CLASS:PRIVATE
CATEGORIES:BUSINESS,HUMAN RESOURCES
END:VEVENT

5.4.2 To-do Component

A To-do Calendar Component is a grouping of component properties and
an optional alarm calendar component that
contains the property value. The value can also be specified as being
contained within represent an another, external message using the _MESSAGE-ID_
value, action-item or _MID_ for shorthand. In addition, the property value can be
specified as being located out on the Internet using the _URL_ value.
In this case, the property value is the Uniform Resource Locator for
the Internet resource containing the property value. This property
parameter
assignment. For example, it may be used on any property. However, the use an item of this
parameter on some properties may not make sense; for example work assigned to an
individual; such as "turn in travel expense today".

A To-do Component is defined by the
Version, Time Zone, Status, Priority, Mail Reminder, etc. properties.

The following specifies a value located out on the Internet:

ATTACH;VALUE=URL:http://www.abc.com/dir_photos/my_photo.gif notation:

todoc = "BEGIN" ":" "VTODO" CRLF
*todoprop *alarmc
"END" ":" "VTODO" CRLF

todoprop = *attach *attendee *categories [class] [completed]
/ [created] description dtstart due *exdate
/ *exrule *last-mod [location] priority
/ *related *resources *rdate *rrule [resp-seq]
/ [seq] [status] [summary] [transp] [uid] *url

The following specifies a value located out in the content of To-do Component can not be nested within another
message:

ATTACH;VALUE=MID:<960120.aaCB@host1.com>

3.1.3.10 Binary Property Values

The iCalendar Object supports inclusion of binary information, such
as computer graphic images (e.g., IMAGE/JPEG), digital audio (e.g.,
AUDIO/BASIC), Calendar
Component. If To-do components need to be related to each other or video graphic images (e.g., VIDEO/MPEG). As
specified above the binary information to
an Event or Journal Calendar Component, they can be referenced with specify a
Uniform Reference Locator (URL), referenced within
relationship with the RELATED-TO property.

Dawson/Stenerson 23 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

The following is an external MIME
message, referenced within example of a particular MIME message body part, or
placed inline. Inline binary information To-do Calendar Component:

BEGIN:VTODO
DTSTART:19970415T083000-0500
DUE:19970415T235959-0500
DESCRIPTION:1996 Income Tax Preparation
CLASS:CONFIDENTIAL
CATEGORIES:FAMILY,FINANCE
PRIORITY:1
STATUS:NEEDS ACTION
END:VEVENT

5.4.3 Journal Component

A Journal Calendar Component is included as a property
value after being binary encoded using Base 64 (default) grouping of component properties
that represent one or Quoted-
Printable transfer encoding.

3.1.3.11 Recurrence Rule Grammar

Recurring events within the iCalendar Object more descriptive text on a particular calendar
date. For example, it may be specified as
either a list journal entry of discrete date and time values individual telephone
contacts for the day or as a recurrence
rule using a grammar. The basic recurrence rule grammar used by this
specification an ordered list of accomplishments for the
day.

A Journal Component is defined in a separate section of this specification. by the following notation:

journalc = "BEGIN" ":" "VJOURNAL" CRLF
*jourprop
"END" ":" "VJOURNAL" CRLF

jourprop = *attach *categories [class] [created] description
/ dtstart *last-mod *related [resp-seq] [seq] [uid] *url

The grammar defines Journal Component can not be nested within another Calendar
Component. If Journal Components need to be related to each other or
to an Event or To-Do Calendar Component, they can specify a recurrence rule that that is based on
relationship with the prior
work RELATED-TO property.

The following is an example of the X.400 API Association's Calendaring Journal Calendar Component:

BEGIN:VJOURNAL
DTSTART:19970317T083000
DESCRIPTION:1. Staff meeting: Participants include Joe, Lisa
and Scheduling
Subcommittee. It Bob. Aurora project plans were reviewed. There is also based currently
no budget reserves for this project. Lisa will escalate to
management. Next meeting on prior work Tuesday.
2. Telephone Conference: ABC Corp. sales representative called
to discuss new printer. Promised to get us a demo by Friday.
3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
Is looking into a loaner car. 654-2323 (tel).
END:VJOURNAL

5.4.4 Free/Busy Component

A Free/Busy Calendar Component is a grouping of the IETF Chronos
Working Group. Refer component properties
that represent free or busy time information. Typically, this
component exists in an iCalendar Object that is being used to section 3.3. either
request or return free or busy time information.

Dawson/Stenerson 19 24 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.4 Body Delimiter Properties

The body information of a iCalendar Object

A Free/Busy Component is defined by a series of
body fields or properties. This section defines the properties that following notation:

freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
*fbprop
"END" ":" "VFREEBUSY" CRLF

fbprop = *attendee [created] [duration] [dtend] [dtstart]
/ *freebusy *last-mod *related [resp-seq] [seq] [uid]
/ *url

The Free/Busy Component can not be used in MIME entities conforming to this content type.

3.1.4.1 nested within another Calendar Object

The body of
Component. Free/Busy components may be related to each other with the iCalendar Object is identified
RELATED-TO property. Multiple Free/Busy Calendar Components may be
specified within the body of a
MIME entity by iCalendar Object. This permits the appearance grouping of the Begin Calendar Object Delimiter:

BEGIN:VCALENDAR

The sentinel string must appear
Free/Busy information into logical collections, such as the first characters in the body monthly
groups of the MIME entity busy time information.

The Free/Busy Calendar Component is intended for use in profiles
involving requests for free time, requests for busy time, requests
for both free and busy, and as the first characters on a line.

The body associated replies.

Free/Busy information of the iCalendar Object is terminated by can be expressed using the
appearance FREEBBUSY property.
This property provides a terse representation of time periods. One or
more FREEBUSY properties may be specified in the End FREE/BUSY Calendar Object Delimiter as
Component to describe the first
characters on a line:

END:VCALENDAR

The iCalendar Object is a container Free/Busy information.

Optionally, the DTSTART and DTEND properties may be specified to
express the start and end date and time for calendar components. These
can include either event or to-do components. The body of Free/Busy information in
the Free/Busy Calendar Component. When present in a iCalendar
Object will generally contain Free/Busy
Calendar Component, they should be specified prior to any FREEBUSY
properties. In a single calendar event or to-do
component. However, the body free time request, these properties may include multiple event or to-do
components. This is be used in
combination with the case DURATION property to express a request for free-busy time reply messages that
contain multiple a
duration of free time intervals in individual calendar
components. within a given window of time.

The Begin and End Calendar Object Delimiter recurrence properties (RRULE, EXRULE, RDATE, EXDATE) are required
in not
permitted within a MIME entity conforming to this content type. Free/Busy Calendar Component. Any recurring events
are resolved into their individual busy time periods using the
FREEBUSY property.

The data type for
these properties following is an example of a STRING.

3.1.4.2 Event Free/Busy Calendar Component:

BEGIN:VFREEBUSY
DTSTART:19971015T050000Z
DTEND:19971016T050000Z
FREEBUSY;VALUE=PERIOD-START:19971015T050000Z/PT8H30M,
19971015T160000Z/PT5H30M, 19971015T223000Z/PT6H30M
END:VFREEBUSY

5.4.5 Alarm Component

An Event Alarm Calendar Component is a grouping of calendaring and scheduling
properties that defines a component properties
that represents is a scheduled
amount of time on reminder or alarm for an event or a calendar. For example, it to-do. The Alarm
Calendar Component may only be specified in an activity;
such as a one-hour, department meeting from 8 AM to 9 AM, tomorrow event or
a free/busy time interval.

An individual Event Component is identified within a MIME Calendaring
and Scheduling Content Type by the appearance of the delimiter:

BEGIN:VEVENT

The sentinel string must appear as the first characters on a line.

The Event Component is terminated with the appearance of the
following delimiter string as the first characters on a line

END:VEVENT to-do

Dawson/Stenerson 20 25 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

calendar component. For example, it may define a reminder for a
pending event or an overdue to-do.

An Alarm Component is defined by the following notation:

alarmc = "BEGIN" ":" "VALARM" CRLF
*alarmprop
"END" ":" "VALARM" CRLF

alarmprop = *attach [created] [description] dtstart duration
/ *last-mod *related repeat [summary] *url

The Event Alarm Component can not be nested only appear within another either an Event or To-do To-Do
Calendar Component. If Event components need to be related to each other or to
a To-do Component, they Alarm Components can specify a relationship with the RELATED-
TO property.

The Begin and End Event Component Delimiter properties are required
for a MIME entity containing an event component and conforming to
this content type. not be nested.

The data type for these properties is a STRING.

3.1.4.3 To-do Component

A To-do Component following is a grouping of calendaring and scheduling
properties that define a component that represents an action-item or
assignment. For example, it may be an item example of work assigned to an
individual; such as _turn in travel expense today_.

An individual To-do the Alarm Calendar Component:

BEGIN:VALARM
DTSTART:19970317T133000Z
REPEAT:4
DURATION:PT15M
CATEGORIES:DISPLAY,AUDIO
ATTACH:file:///mmedia/sounds/bell1.wav
DESCRIPTION:Breakfast meeting with executive team at 8:30 AM
END:VALARM

5.4.6 Timezone Component

A time zone is identified within a MIME Calendaring
and Scheduling Content Type unambiguously defined by the appearance set of time measurement
rules determined by the delimiter:

BEGIN:VTODO

The sentinel string must appear as the first characters on governing body for a line.

The To-do Component is terminated with given geographic area.
These rules describe at a minimum the appearance of base offset from UTC for the
following delimiter string
time zone, often referred to as the first characters on a line

END:VTODO

The To-do Component can not be nested within another To-do Standard Time offset. Many
locations adjust their Standard Time forward or Event
Component. If To-do components need to be related backward by one hour,
in order to each other or accommodate seasonal changes in number of daylight hours,
often referred to
an Event Component, they can specify as Daylight Saving Time. Some locations adjust
their time by a relationship with the RELATED-
TO property. 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 Begin following table
shows the changes in time zone rules for the eastern United States.

Effective Transition Rule
Date (Date/Time) Offset Abbreviation

1967-* last Sun in October, 02:00 -0500 EDT

1967-1973 last Sun in April, 02:00 -0400 EST

1974-1974 Jan 6, 02:00 -0400 EST

1975-1975 Feb 23, 02:00 -0400 EST

1976-1986 last Sun in April, 02:00 -0400 EST

1987-* first Sun in April, 02:00 -0400 EST

Dawson/Stenerson 26 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

Interoperability between two calendaring and End To-do Component Delimiter properties are required scheduling applications,
especially for a MIME entity containing a to-do component recurring events and conforming to-dos, is dependent on the
ability to this
content type. capture and convey date and time information in an
unambiguous format. The data type for these properties specification of current time zone
information is a STRING.

3.1.5 Calendar Object Properties integral to this behavior.

The following properties may appear between the Begin Time Zone Calendar Object
Delimiter and either the Begin Event Component Delimiter or the Begin
To-do Component Delimiter. These is a grouping of component
properties define body field values that apply to define a time zone description. The time zone
description specifies the complete calendar object.

3.1.5.1 effective Standard Time or Daylight Savings
Time rules for a particular time zone. The Timezone Component can not
be nested within other Calendar Content Profile

This property is identified by the property name PROFILE. This
property defines Components. The Time Zone Component
may be specified multiple times. If the usage profile associated with Time Zone Component is
missing, the calendar
object. When used in a MIME message entity, recipient should assume all local times are relative to
the value of this
property MUST recipient's time zone. The Time Zone Component should be the same as the Content-Type profile parameter
value. This property can only appear once within
specified in the iCalendar
Object.

Dawson/Stenerson 21 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

The calendar property value might include before any other Calendar
Components.

A Time Zone Component is defined by the following usage profile
values:

Profile Parameter Description
Type/Subtype Value

EVENT-REQUEST Make a request notation:

timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
*tzprop
"END" ":" "VTIMEZONE" CRLF

tzprop = [created] [daylight] [dtend] dtstart [rdate / rrule]
[tzname] tzoffset [tztrans] [uid]

The Time Zone component is especially important for correct
interpretation of recurring events and to-dos. If the iCalendar
Object contains an event

EVENT-REPLY Reply to an event
request

EVENT-COUNTER Make or to-do component that has a counter proposal
to recurring date
pattern (i.e., includes the event request

EVENT-DECLINECOUNTER Decline RRULE property) or a list of date and
local time values (i.e., includes the counter
proposal to RDATE property), one or more
Time Zone components must be specified, such that for the event
request

EVENT-MODIFY Modify a subset given range
of the
details recurrence (i.e., the earliest instance to latest instance),
there is valid time zone information for all instances. In other
words, if all of an existing
event request

EVENT-REPLACE Replace the current
event request with a
complete set of
information

EVENT-CANCEL Cancel an existing
event request

EVENT-DELEGATE Delegate an existing
event request

EVENT-RESEND Request a duplicate instances of the current event
request information

TODO-REQUEST Assign pattern is entirely within one
offset observance, (e.g., all are in Standard Time), only one Time
Zone Calendar Component need be present. If a to-do

Dawson/Stenerson 22 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

TODO-REPLY Reply time zone transition is
crossed, then other Time Zone Components are needed. Further, if
there are known changes to the rules for the time zone, even more
Time Zone Components are needed.

Each Time Zone Component consists of several properties. The CREATED
property is a to-do
assignment

TODO-COUNTER Make DATE-TIME value that indicates when the time zone
description was created; the DAYLIGHT property is a counter proposal
for BOOLEAN value
indicating Standard Time (FALSE) or Daylight Savings Time (TRUE); the to-do request

TODO-DECLINECOUNTER Decline
DSTART property is a counter
proposal DATE-TIME value indicating the effective start
for the to-do
request

TODO-MODIFY Modify time zone information; the DTEND property is a subset of DATE-TIME
value indicating the
details of an existing
to-do assignment

TODO-REPLACE Replace effective end date for the current to-
do request with time zone
information; the TZOFFSET property is a
complete set of
information

TODO-CANCEL Cancel an existing to-
do

TODO-DELEGATE Delegate an existing
to-do

TODO-RESEND Request UTC-OFFSET value indicating
the UTC offset for the time zone (Standard Time or Daylight Savings
Time); the TZTRANS property is a duplicate of TIME value indicating the current to-do
request information

FREEBUSY-REQUEST Free/busy time request

FREEBUSY-REPLY Reply of
day after which the transition to an existing
free/busy the time request
with free/busy zone occurs; the TZNAME
property is the customary name for the time
data

Other values may be defined by other usage profiles of this content
type. zone; the RRULE property
is a TEXT property indicating the recurrence rule for the transition

Dawson/Stenerson 23 27 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

This property is optional for MIME entities conforming

to this
content type. In time zone or alternatively, the event that this RDATE property is not specified, the
recipient of a MIME Calendaring DATE-TIME
property indicating the individual dates and Scheduling Content Type should
assume times that the calendar object
transition takes effect; and the UID is a TEXT value indicating a
globally unique identifier for an _event/request_. the time zone.

The data type default for this property DAYLIGHT is STRING.

3.1.5.2 FALSE or Standard Time.

The following are examples of the Time Zone Calendar Component:

BEGIN:VTIMEZONE
DAYLIGHT:FALSE
DTSTART:19670101T000000
RRULE;BYDAY=-1SU;BYMONTH=10:YEARLY
TZTRANS:020000
TZOFFSET:-0500
TZNAME:EST
END:VTIMEZONE

BEGIN:VTIMEZONE
DAYLIGHT:TRUE
DTSTART:19870101T000000
RRULE;BYDAY=1SU;BYMONTH=4:YEARLY
TZTRANS:020000
TZOFFSET:-0400
TZNAME:EDT
END:VTIMEZONE

5.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
properties and prior to any Calendar Component.

5.4.7.1 Calendar Scale

This property is identified by the property name CALENDAR. CALSCALE. This
property defines the calendar scale used for the calendar information
specified in the iCalendar Object. This specification 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 specification.

The property is defined by the following notation:

calscale = "CALSCALE" ":" calvalue CRLF

calvalue = "GREGORIAN" / iana-scale

iana-scale = <Any other designator for a calendar scale
registered with IANA>

The following is an example of this property:

CALENDAR:GREGORIAN

Dawson/Stenerson 28 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

CALSCALE:GREGORIAN

The data type for this property is STRING.

3.1.5.3 Daylight Savings Rule TEXT.

5.4.7.2 Geographic Position

This property is identified by the property name DAYLIGHT. GEO. This property defines the effective daylight savings time rule for
calendar
specifies information specified in related to the iCalendar Object. More than one
DAYLIGHT properties can be specified for a series global position of future DST rules
for the time zone.

Many locations adjust their standard time forward or backward by one
hour, in order to accommodate seasonal changes in number of daylight
hours. Some locations adjust their time entity
represented by a fraction of an hour.
Standard time is also known as Winter Time. Daylight savings time is
also known as Advanced Time, Summer Time, or Legal Time in certain
countries. the iCalendar Object. The property value consists of a sequence of components that define a
rule for specifies
longitude and latitude. The longitude represents the observance location east
and west of daylight savings time. The value consists
of effective start date for the DST rule, followed by the daylight
savings time flag, followed by the daylight savings time offset from
UTC, followed by prime meridian as a positive or negative real number,
respectively. The latitude represents the date location north and time south of
the transition from standard
time to daylight savings time, followed equator as a positive or negative real number, respectively.

The property is defined by the date and time following notation:

geo = "GEO" ":" geovalue CRLF

geovalue = (float ";" float )/ url

The following is an example of the
transition from daylight savings time to standard time, followed by
the customary standard time designation, followed by the customary
daylight savings time designation. this property:

GEO:37.24,-17.87

The effective start date for the
DST rule allows default data type for this property is FLOAT. Optionally, the specification of a series of future DST rules
data type for a given time zone. this property may be URL. The daylight savings time flag is TRUE if
daylight savings time URL is observed, otherwise it the resource
location for the geographical position value.

5.4.7.3 Product Identifier

This property is FALSE and no other
components are specified. identified by the property name PRODID. This
property specifies the identifier for the product that created the
iCalendar Object. The daylight savings time offset value vendor of the implementation should assure that
this is
specified in a manner consistent with globally unique identifier; using some technique such as an
ISO 8601. 9070 FPI value. This calendar property must be specified in the
iCalendar Object but can only appear once.

The property value is
a signed numeric indicating defined by the number of hours following notation:

prodid = "prodid" ":" pidvalue CRLF

pidvalue = (text / url)
;Any text that describes the product and possibly minutes
from UTC. The date and time version
;and that is generally assured of being unique.>

The following is an example of this property:

PRODID:-//ABC Corporation//NONSGML My Product//EN

The default data type for this property is TEXT. Optionally, the daylight savings time begins and
ends data
type may be URL. The URL is specified in a manner consistent with ISO 8601 date and time the resource location for the product
identifier value.

Dawson/Stenerson 24 29 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

format.

5.4.7.4 Profile

This property is identified by the property name PROFILE. This
property defines the usage profile associated with the calendar
object. When used in a MIME message entity, the value of this
property must be the same as the Content-Type profile parameter
value. This property can only appear once within the iCalendar
Object.

The standard time and daylight savings time designations
correspond to property is defined by the customary character designations. following notation:

profile = "PROFILE" ": profvalue CRLF

profvalue = " component "-" action

component = "EVENT" / "TODO" / "JOURNAL" / "FREEBUSY"
/ iana-component / x-token

action = <Any IANA registered iCalendar action type.>

iana-component = <Any other component registered with IANA>

The following are examples is an example of this property:

DAYLIGHT:19960407;TRUE;-06;19960407T025959;19961027T010000;EST;EDT

DAYLIGHT:FALSE

DAYLIGHT:19960407;TRUE;-09;19960407T115959;19961027T100000;PST;PDT

This property when the iCalendar
Object is optional for MIME entities conforming used to this
content type. request a meeting:

PROFILE:EVENT-REQUEST

In the event that this property is not specified, the
recipient of a MIME Calendaring and Scheduling Content Type should
assume the same daylight savings time rule as the recipient location. usage profile
is undefined. The data type for this property is DST-RULE.

3.1.5.4 Geographic Position TEXT.

5.4.7.5 Profile Version

This property is identified by the property name GEO. PROFILE-VERSION.
This property specifies information related the identifier corresponding to the global position highest
version number of the _home_
system usage profile that created was used in constructing the MIME calendar object. The
iCalendar Object. Values for this property value
specifies longitude and latitude. are to be defined by
registering an iCalendar usage profiles.

The longitude represents the
location east and west of the prime meridian as a positive or
negative real number, respectively. The latitude represents the
location north and south of property is defined by the equator as a positive or negative
real number, respectively. following notation:

prof-version = "PROFILE-VERSION" ":" profvalue CRLF

profvalue = iana-prfver / x-token

iana-prfver = <A IANA registered iCalendar profile identifier>

The following is an example of this property:

GEO:37.24,-17.87

This property is optional for MIME entities conforming to this
content type.

PROFILE-VERSION:IPCS-1.0

The default data type for this property is FLOAT-LIST.
Optionally, the data type for this property may be URL. The URL is
the resource location for the geographical position value.

3.1.5.5 Product Identifier TEXT.

Dawson/Stenerson 30 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

5.4.7.6 Source

This property is identified by the property name PRODID. SOURCE. This
property specifies is defined by the identifier for [MIME DIR] specification. The property
identifies the product that created URL for the
MIME calendar object. The vendor source of the implementation should assure
that this is iCalendar Object. The source
will usually be a globally unique identifier; using some technique such
as an ISO 9070 FPI value. resource on a calendaring and scheduling service.

The property is defined by the following notation:

source = "SOURCE" ":" url CRLF

The following is an example of this property:

PRODID:-//ABC Corporation//NONSGML My Product//EN

This property is required for MIME entities conforming to this
content type.

SOURCE:http://xyz.corp.com/corp-cals/1997-events.or4

The default data type for this property is STRING.
Optionally, the data type may be URL. The URL is the resource
location for the product identifier value.

Dawson/Stenerson 25 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

3.1.5.6 Time Zone

5.4.7.7 Source Name

This property is identified by the property name TZ. NAME. This property
specifies
is defined by the standard time zone of [MIME DIR] specification. The property identifies
the _home_ system that created displayable, presentation name for the MIME calendar object. source of the iCalendar
Object. The property value source name is specified in a manner
consistent useful text to associate in the user-
interface of an application with ISO 8601. The property the value in the SOURCE property.

The property is a signed numeric
indicating defined by the number of hours and possibly minutes from UTC. Time
zones east of UTC are positive numbers. Time zones west of UTC are
negative numbers. following notation:

name = "NAME" ":" text CRLF

The following are examples is an example of this property:

TZ:-0500

TZ:+05:30

This property is optional

NAME:1997 Events Calendar for MIME entities conforming to this
content type. If this property is missing, the recipient should
assume all local times are relative to the recipients time zone. XYZ Corporation

The data type for this property is TIME-OFFSET. Optionally, TEXT.

5.4.7.8 Version

This property is identified by the data type
for this property may be STRING.

3.1.5.7 Version name VERSION. This
property specifies the identifier corresponding to the highest
version number of the MIME Calendaring and Scheduling Content Type
specification supported by the implementation that created the MIME
calendar object.
iCalendar Object. The value of this property must be 2.0 "2.0" to
correspond to this specification.. specification. This calendar property must appear
within the iCalendar Object but can only appear once.

The property is identified defined by the property name VERSION. following notation:

version = "VERSION" ":" vervalue CRLF

vervalue = "2.0" / x-token

The following is an example of this property:

VERSION:2.0

This property is required for MIME entities conforming to this
content type. This property must appear within the MIME calendar
object.

Dawson/Stenerson 31 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

The data type for this property is FLOAT.

3.1.6 Event and To-do TEXT.

5.5 Component Properties

The following properties apply to either an event or to-do calendar
object component.

3.1.6.1

5.5.1.1 Attachment

This property is identified by the property name ATTACH. The property
defines
provides the capability to associate an attached external object to the MIME with a
calendar object. component. For example, a document to be reviewed at a
scheduled event or the description of the process steps for a to-do.
The property value can may only be a text string, a reference to
another message body part specified within event, to-do, or a reference to a URL corresponding to a
document.

Multiple attachments journal
calendar components. This property may be specified by including multiple ATTACH
properties times
within an iCalendar Object.

The property is defined by the MIME calendaring entity.

Dawson/Stenerson 26 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997 following notation:

attach = [group "."] "ATTACH" ":" url CRLF

The following are examples of this property:

ATTACH;VALUE=CONTENT-ID:<jsmith.part3.960817T083000.
xyzMail@host1.com>

ATTACH;VALUE=URL:file://xyzCorp.com/pub/reports/r-960812.ps

This property is optional for MIME entities conforming to this
content type.

ATTACH:<jsmith.part3.960817T083000.xyzMail@host1.com>

ATTACH://xyzCorp.com/pub/reports/r-960812.ps

The default data type for this property is MID. The
data type may alternatively be specified to be CID, URL, or STRING
value.

3.1.6.2 URL.

5.5.1.2 Attendee

This property is identified by the property name ATTENDEE. The
property defines an attendee to within a group event or to-do. calendar component. The default
property value is an (RFC 822) address. may only be specified within the event, to-do and free/busy
calendar components.

The property may include has the property parameters TYPE, for the type of
attendee, ROLE, for the intended role of the attendee in the event or to-do; attendee; STATUS, for
the status of the attendee's participation in the event or to-do, participation; RSVP, for indicating
whether the favor of a reply is requested, requested; EXPECT, to indicate the
expectation of the attendee's participation by the
originator, originator; and
MEMBER, to indicate the group that the attendee belongs to.

Multiple attendees may be specified by including multiple ATTENDEE
properties within the MIME calendaring entity.

The property value data type default is RFC822-ADDRESS. The property data
type may reference a vCard object. also be set to URL. This provides a useful mechanism to
allow more than just the address of the attendee to be referenced.
For example, the property value may refer to a URL.

The TYPE property parameter for each attendee can have is defined by the following
values: notation:

Dawson/Stenerson 27 32 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

Property Description
Value

INDIVIDUAL Indicates

attendee is
an
individual.

GROUP Indicates
attendee is a = [group "."] "ATTENDEE" [";" attparamlist] ":"
(rfc822-address / URL) CRLF
;Value must match default or explicit data type

attparamlist = attparam / attparamlist ";" attparam
/ paramlist / paramlist ";" attparam
/ paramlist ";" attparamlist ";" attparam

attparam = typeparm / roleparm / statusparm / rsvpparm
/ expectparm / memberparm

typeparm = "TYPE" "="
("INDIVIDUAL" ; An individual
/ "GROUP" ; A group of
individuals.

RESOURCE Indicates
attendee individuals
/ "RESOURCE" ; A physical resource
/ "ROOM" ; A room resource
/ "UNKNOWN") ; Otherwise not known
;Default value is a
resource. UNKNOWN

roleparm = "ROLE" "="
("ATTENDEE" ; Indicates a regular attendee type
is unknown.

The ROLE property parameter for each attendee can have the following
values:

Property Description
Value

ATTENDEE
/ "OWNER" ; Indicates an
attendee at
the owner of event or to-do

ORGANIZER
/ "ORGANIZER" ; Indicates organizer of
the event,
but not owner

OWNER Indicates
owner of the event or to-
do.

Dawson/Stenerson 28 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

DELEGATE to-do
/ "DELEGATE") ; Indicates a delegate of
another
attendee.

The default value for this property parameter to event or to-do
;Default is ATTENDEE.

The STATUS property parameter for each attendee can have the
following values:

Property Description
Value

ACCEPTED Indicates to-
do was
accepted by
attendee

NEEDS ACTION ATTENDEE

statusparm = "STATUS" "="
("NEEDS-ACTION" ; Indicates event or to-
do requires to-do needs action by
attendee

SENT
/ "ACCEPTED" ; Indicates event or to-
do was sent
out to
attendee

TENTATIVE Indicates
event is
tentatively to-do accepted by
attendee

CONFIRMED
/ "DECLINED" ; Indicates
attendee has
confirmed
their
attendance at
the event

DECLINED or to-do not accepted
/ "TENTATIVE" ; Indicates event or to-

Dawson/Stenerson 29 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

do has been
rejected by
attendee

COMPLETED to-do tentatively
; accepted. Status may change in the future.
/ "COMPLETED" ; Indicates to-
do to-do was completed.
; COMPLETED property has been
completed by
attendee

DELEGATED Indicates date/time completed.
/ "DELEGATED" ; Indicateds event or to-
do has been to-do delegated by
the attendee
; to another

CANCELED ATTENDEE
/ "CANCELED") ; Indicates the event or to-
do has been to-do canceled
and/or this
attendee has
been removed
from the list
of attendees.

The default value for this property parameter
; ATTENDEE
;Default is NEEDS ACTION.

The RSVP property parameter for each attendee can have the following
values:

Property Description
Value

YES Indicates a
reply NEEDS-ACTION

rsvpparm = "RSVP" "=" ("YES" / "NO")
;Default is
requested NO Indicates a
reply is not
requested.

The default value for this property parameter is NO.

Dawson/Stenerson 30 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

The EXPECT property parameter for each attendee can have the
following values:

Property Description
Value

FYI

expectparm = "EXPECT" "="
("FYI" ; Indicates request is for your
information.

REQUIRE info
/ "REQUIRE" ; Indicates presence is
definitely
required.

REQUEST required
/ "REQUEST" ; Indicates presence is
being requested

IMMEDIATE
/ "IMMEDIATE") ; Indicates an immediate response
needed.

The default value for this property parameter is FYI.

The MEMBER property parameter value needed
;Default is an (RFC 822) address that
represents the FYI

memberparm = rfc822-address ; Indicates a group or distribution list. mailing list

The following is an example of this property's use for a to-do:

Dawson/Stenerson 33 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:jsmith@host1.com

The following is an example of this property used for specifying
multiple attendees to an event:

ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:John Smith <jsmith@host1.com>
ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:Henry Cabot
<hcabot@host2.com>
ATTENDEE;ROLE=DELEGATE;STATUS=CONFIRMED:Jane Doe <jdoe@host1.com>

The following is an example of this property with the value specified
as an URL reference to a vCard that contains the information about
the attendee:

Dawson/Stenerson 31 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;VALUE=URL:
http://www.xyz.com/~myvcard.vcf

This property is optional for MIME entities conforming to this
content type.

The default data type for this property is RFC822-
ADDRESS. Optionally, the RFC822-ADDRESS. The data
type for this property may be URL, MID,
or CID; reset to URL; in which case the value is a location or
message that contains the information that is to be used to specify
the attendee.

3.1.6.3 Audio Reminder attendee address.

5.5.1.3 Categories

This property is identified by the property name AALARM. The CATEGORIES. This
property defines an audio reminder for the MIME categories for a calendar object. An audio
reminder is an alarm that is sounded for a calendar component.. component. The value for the audio reminder consists of
property may be specified within the Run Time, event, to-do or the
date and time that the reminder is to journal calendar
component with an arbitrary text value. The property may also be executed; Snooze Time, or
specified within the duration alarm property with a value of time after the Run Time that the reminder is to alarm
category. More than one category may be
dormant prior to being repeated; Repeat Count, or the number specified as a list of times
that
categories separated by the reminder COMMA character (ASCII decimal 44).

The properties is to be repeated; and the Audio Content, or the
digital sound to be played when defined by the reminder is executed. following notation:

categories = "CATEGORIES" [";" paramlist] ":" catvalue CRLF

catvalue = cat1value [,cat1value] / cat2value [, cat2value]

cat1value = "APPOINTMENT" / "BUSINESS" / "EDUCATION" / "HOLIDAY"
/ "MEETING" / "MISCELLANEOUS" / "NON-WORKING HOURS"
/ "NOT IN OFFICE" / "PERSONAL" / "PHONE CALL"
/ "SICK DAY" / "SPECIAL OCCASION" / "TRAVEL"
/ "VACATION" / word
;Used in event and to-do components only

cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
/ x-token / iana-word
;Used in alarm component only

The following are some examples of this property:

AALARM;TYPE=WAVE;VALUE=URL:19960415T235959; ; ;
file:///mmedia/taps.wav

AALARM;TYPE=WAVE;VALUE=CONTENT-
ID:19960903T060000;PT15M;4;<jsmith.part2.=
960901T083000.xyzMail@host1.com>

The property has the following additional property parameters:

Property Description
Parameter
Values

TYPE

- - Any IANA Indicates a
registered MIME audio
audio content
content type type.
value - -

WAVE Indicates
the WAVE
format for
audio
content. in an event, to-do or
journal calendar component:

CATEGORIES:APPOINTMENT,EDUCATION

Dawson/Stenerson 32 34 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

AIFF Indicates
the AIFF
format for
audio
content.

CATEGORIES:MEETING

The Reminder properties following are primarily provided as a means for
allowing the capture examples of alarm information when accessing a calendar
system. It may not be an appropriate this property to send in an event or
to-do request.

This property is optional for MIME entities conforming to this
content type. alarm calendar
component:

CATEGORIES:AUDIO,DISPLAY

CATEGORIES:PROCEDURE

The default data type for this property is AALARM.
Optionally, the data type may be specified to be CID, MID, or URL.

3.1.6.4 Categories TEXT.

5.5.1.4 Classification

This property is identified by the property name CATEGORIES. CLASS. This property
defines the categories access classification for the MIME a calendar component. More
than one category The
property may only be specified as a list of categories separated
by the Semi-Colon character (ASCII decimal 59).

The following are some examples of this property:

CATEGORIES:APPOINTMENT;EDUCATION

CATEGORIES:MEETING

Some of the possible values for this property might include the
following:

Some Possible

Property Values

APPOINTMENT

BUSINESS

EDUCATION

HOLIDAY

MEETING

MISCELLANEOUS

Dawson/Stenerson 33 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

NON-WORKING-HOURS

NOT-IN-OFFICE

PERSONAL

PHONE CALL

SICK DAY

SPECIAL OCCASION

TRAVEL

VACATION

This property is optional for MIME entities conforming to this
content type. The data type for this property is STRING-LIST.

3.1.6.5 Classification

This property is identified by the property name CLASS. This property
defines the access classification for the MIME in an event, to-do or journal calendar
component.

A calendar event/to-do The property may only be specified once.

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 MIME calendaring entity iCalendar component is useful when
measured along with the other security components of a calendar
system (e.g., user authorization, access rights, access role, etc.).
Hence, the semantics of the individual access classifications can not
be completely defined by this specification. specification alone. Additionally, due
to the _blind_ "blind" nature of most exchange processes using this
specification, these entity access classifications can not serve as an
enforcement statement for a system receiving a MIME calendar
object an iCalendar Object .
Rather, they provide a method for capturing the intention of the
calendar owner for the access to the MIME calendar object component.

The property is defined by the following notation:

class = "CLASS" [";" paramlist] ":" classvalue CRLF

classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / x-token
;Default is PUBLIC

The following is an example of this property:

CLASS:PUBLIC

The data type for this property can have is TEXT.

5.5.1.5 Date/Time Created

This property is identified by the following values: property name CREATED. This
property specifies the date and time that the calendar information
was created. The property may be specified in any of the calendar
components. The property may only be specified once. The date and
time is an UTC value.

Dawson/Stenerson 34 35 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

Property Description
Value

PUBLIC Indicates
general,
public
access.

PRIVATE Indicates
restricted,
private
access.

CONFIDENTIAL Indicates
very
restricted,
confidential
access.

The default value for this property is PUBLIC.

This property defined by the following notation:

created = "CREATED" ":" date-time CRLF

The following is optional for MIME entities conforming to an example of this
content type. property:

CREATED:19960329T133000Z

The data type for this property is STRING.

3.1.6.6 DATE-TIME.

5.5.1.6 Date/Time Created Completed

This property is identified by the property name DCREATED. COMPLETED. This
property specifies defines the date and time that the MIME calendar component a to-do was created within the originating calendar system. This is not
necessarily the same date and time that the MIME calendar object was
created. actually
completed. The property may be specified once in a to-do component.
The date and time value is the local or a UTC based time
expressed in value.

The property is defined by the complete representation, basic or extended format as
specified in ISO 8601. following notation:

completed = "COMPLETED" ":" date-time CRLF

The following is an example of this property:

DCREATED:19960329T083000-0500

COMPLETED:19960401T235959Z

This property is optional for MIME entities conforming to this
content type. The data type for this property is DATE-TIME.

3.1.6.7 Date/Time Completed

5.5.1.7 Daylight

This property is identified by the property name COMPLETED. DAYLIGHT. This
property defines may only be specified in a Time Zone Calendar Component.
This property specifies whether Daylight Saving Time (i.e., value is
TRUE) or Standard Time (i.e., value is FALSE) is in effect for the date and
time that the to-do was actually
completed. zone. The date and time default value is expressed in the complete
representation, basic FALSE or extended format as specified in ISO 8601. Standard Time.

The time can either be in local or UTC based time. property is defined by the following notation:

daylight = "DAYLIGHT" ":" boolean CRLF
;Default value is FALSE

The following is an example of this property:

Dawson/Stenerson 35 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

COMPLETED:19960401T235959Z

This property is optional for MIME entities conforming to this
content type.

DAYLIGHT:TRUE ;Specifies DST in effect in time zone

The data type for this property is DATE-TIME.

3.1.6.8 BOOLEAN.

5.5.1.8 Description

This property is identified by the property name DESCRIPTION. This
property provides a more complete description of the MIME calendar
component, than that provided by the SUMMARY property. The property
must be specified in the event, to-do and journal calendar

Dawson/Stenerson 36 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

components. The property may be specified multiple times only within
a journal calendar component.

The property is defined by the following notation:

description = "DESCRIPTION" [";" paramlist] text CRLF

The following is an examples of the property with formatted line
breaks in the property value:

DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Meeting to provide technical=
review for _Phoenix_ "Phoenix" design.=0D=0A=
Happy Face Conference Room. Phoenix design team=
must attend this meeting. RSVP to team leader.

The following is an examples 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.

This property is required for MIME entities conforming to this
content type.

The data type for this property is STRING. Optionally,
the data type may be URL, MID, or CID.

3.1.6.9 Display Reminder TEXT.

5.5.1.9 Due Date/Time

This property is identified by the property name DALARM. The DUE. This property
defines a display reminder for the MIME calendar component. A display
reminder is an alarm that is popped up into the user interface or
otherwise visually displayed for a calendar component.

The value for the display reminder consists of the Run Time, or the date and time that the reminder a to-do is expected to be executed; Snooze Time, or
the duration of completed.
The time after the Run Time that the reminder is to can either be
dormant prior to being repeated; Repeat Count, in local time, local time with UTC offset or the number of times
that the reminder is to
UTC time. The property must be repeated; and the Display String, or the
text to specified in a to-do calendar
component, but may only be displayed when the reminder specified once.

The property is executed. defined by the following notation:

due = "DUE" ":" date-time CRLF

The following is an example of this property:

DALARM:19960415T235000-0800;PT5M;2;Your Taxes Are Due !!!

The Reminder properties are primarily provided as a means for
allowing the capture of alarm information when accessing a calendar
system. It may not be an appropriate property to send in an event or
to-do request.

This property is optional for MIME entities conforming to this
content type.

DUE:19960401T235959Z

The default data type for this property is DALARM.
Optionally, the DATE-TIME. The data type
may be specified reset to be CID, MID, or URL.

Dawson/Stenerson 36 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

3.1.6.10 Due Date/Time DURATION.

5.5.1.10 Duration

This property is identified by the property name DUE. This DURATION. The
property
defines the date and time that the to-do is due to be completed. specifies a duration of time. The
date and time value is expressed in the complete representation,
basic or extended format as property may be specified
in ISO 8601. The time can
either be an event calendar component in local or UTC based time. Alternatively, the value may be order to specify a duration of time, expressed in the ISO 8601 format as
event, instead of an explicit end date/time. The property may be
specified in
section 3.1.3.8. In this case, the end is relative to the start of
the MIME calendar component. The following is an example of this
property:

DUE:19960401T235959Z

This property is required for MIME entities consisting of a to-do free/busy calendar component that conforms in order to this content type. specify the
amount of free time being requested. The default
data type for this property is DATE-TIME. Optionally, the data type may be specified as a DURATION.

3.1.6.11 Duration

This in
an alarm calendar component in order to specify the period between
repeating alarms.

The property is identified defined by the property name DURATION. The
property specifies an interval or following notation:

Dawson/Stenerson 37 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

duration of time. This property can
be used with the DTSTART property to specify a relative = "DURATION" ":" duration for
an event (e.g., event starts at 8:00 am and lasts for one hour). The
property can also be used in constructing a free-busy time request
(e.g., find free time periods of 15 minute duration, or longer). CRLF

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

This property is optional for MIME entities conforming to this
content type.

The data type for this property is DURATION.

3.1.6.12 End

5.5.1.11 Start Date/Time

This property is identified by the property name DTEND. DTSTART. This
property
defines may be specified within the date event, free/busy, and time that zone
calendar components.

Within the event component will end. The calendar component, this property defines the start
date and time value is expressed in for the complete representation, basic or
extended format as specified event. The property is required in ISO 8601. event
calendar components. The time can either be in local time, local time
with UTC offset or UTC based time. Alternatively, the value may be a duration
of time, expressed in the ISO 8601 format as specified in section
3.1.3.8. In this case, the end The local time is relative only to the start of the MIME
calendar component. Events may have an end date/time but no be used to
specify date and time values that do not need to be fixed. A
recipient must assume their own time zone for data and time values
that do not include time zone information. Events may have a start
date/time but no end date/time. In that case, the event does not take
up any time.

Within the free/busy calendar component, this property defines the
start date and time for the free or busy time information. The time
must be specified in local time with UTC offset or UTC time.

Within the time zone calendar component, this property defines the
effective start date and time for a time zone specification. This
property is required within time zone calendar components. The time
must be specified as a UTC time.

The property is defined by the following notation:

dtstart = "DTSTART" ":" date-time CRLF

The following is an example of this property:

DTEND:19960401T235959Z

Dawson/Stenerson 37 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

This property is required for MIME entities conforming to this
content type.

DTSTART:19960401T235959-0600

The default data type for this property is DATE-TIME.
The data type may alternatively be specified as a DURATION.

3.1.6.13 Exception Date/Times

5.5.1.12 End Date/Time

This property is identified by the property name EXDATE. DTEND. This property defines
may be specified within the list of date/time exceptions for a recurring
MIME event, free/busy, and time zone calendar component. The
components.

Dawson/Stenerson 38 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

Within the event calendar component, this property defines the end
date and time values is expressed in for the
complete representation, basic format as specified event. The property is required in ISO 8601. event
calendar components. The
times time can either be in local time, local time
with UTC offset or UTC based time. The following is an
example of this property:

EXDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z

This property local time is optional for MIME entities conforming only to this
content type. The data type be used to
specify date and time values that do not need to be fixed. A
recipient must assume their own time zone for data and time values
that do not include time zone information. Events may have an end
date/time but no start date/time. In that case, the event does not
take up any time.

Within the free/busy calendar component, this property is D-T-LIST.
Optionally, defines the data type may
end date and time for the free or busy time information. The time
must be URL; specified in which case local time with UTC offset or UTC time.

Within the value is time zone calendar component, this property defines the
location where
effective end date and time for a list of exception dates can be found. time zone specification. This latter
case
property is required within time zone calendar components. The time
must be specified as a useful method UTC time.

The property is defined by the following notation:

dtend = "DTEND" ":" date-time CRLF

The following is an example of this property:

DTEND:19960401T235959Z

The data type for conveying dynamic this property is DATE-TIME.

5.5.1.13 Exception Date/Times

This property is identified by the property name EXDATE. This
property defines the list of date/time exceptions dates, such
as holidays, for a recurring
event or to-do.

3.1.6.14 to-do component. The times can either be in local time,
local time with UTC offset or UTC time.

The property is defined by the following notation:

exdate = "EXDATE" ":" date-time *["," date-time] CRLF

The following is an example of this property:

EXDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z

The data type for this property is DATE-TIME.

5.5.1.14 Exception Rule

This property is identified by the property name EXRULE. This
property defines a rule or repeating pattern for an exception to a
recurring MIME calendaring entity, based on the Basic Recurrence Rule
Grammar of the [XAPIA]. The value for the event or to-do. This property is a pattern
specification for the recurrence exception. The may only be specified in the
event and to-do calendar components.

Dawson/Stenerson 39 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

This property is defined by the same property values and parameters
as specified for the RRULE property. The property is defined by the
following notation:

exrule = "EXRULE" [";" rparamlist] ":" rvalue CRLF

The following are some examples of this property:

EXRULE:W2 TU TH #2 // property. Except every other week,
on Tuesday
// and Thursday for 4 occurrences

EXRULE:D1 #10 // occurrences:

EXRULE;COUNT=4;INTERVAL=2;BYDAY=TU,TH:WEEKLY

Except daily for 10 occurrences

EXRULE:YM1 6 7 #8 // occurrences:

EXRULE;COUNT=10:DAILY

Except yearly in June and July for 8
// occurrences

This property is optional for MIME entities conforming to this
content type. occurrences:

EXRULE;COUNT=8;BYMONTH=6,7:YEARLY

The data type for this property is RRULE.

3.1.6.15 Last Modified TEXT.

5.5.1.15 Free/Busy Time

This property is identified by the property name LAST-MODIFIED. FREEBUSY. The
property specifies the defines one or more free or busy time intervals. These time
periods may be specified as either a start and end date-time or a
start date-time and duration.

The date and time that the MIME calendar component
was last revised. The following is an example of this property:

LAST-MODIFIED:19960817T133000Z

This either local time with UTC offset or a UTC
value.

The FREEBUSY property is optional for MIME entities conforming may include the TYPE property parameter to this
content type.
specify the information defines a free or busy time interval. The data
property may also include the STATUS property parameter to specify
the type for this of busy time. The STATUS parameter may be utilized by the
application reading the busy time information in order to provide a
richer view of the information.

The property is DATE-TIME. defined by the following notation:

freebusy = "FREEBUSY" [";" fbparmlist] ":" fbvalue CRLF

fbparmlist = fbparam / paramlist ";" fbparam
/ fbparam ";" fbparmlist

fbparam = fbtype / fbstatus

fbtype = "TYPE" "=" ("FREE" or "BUSY")
;Default is BUSY

fbstatus = "STATUS" "="
"BUSY" ;Represents busy time interval
/ "OUT" ;Represents out-of-office, non-working
;hours, or other unavailable interval

Dawson/Stenerson 38 40 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.6.16 Location

This property

/ "PRIVATE" ;Represents private unavailable time
/ "CONFIDENTIAL" ;Represents confidential unavailable
;time
;Default is identified by the property name LOCATION. The
property defines the intended location for the MIME calendar
component.

The property value may reference a vCard object. This provides a
useful mechanism to specify a location in terms of its electronic
business card. BUSY

fbvalue = period *["," period]
;Value must match default or explicit data type

The following are some examples of this property:

LOCATION:Conference Room - F123, Bldg. 002 // or

LOCATION;VALUE=URL:http://www.xyzcorp.com/~jsmith.vcf

This

FREEBUSY;STATUS=OUT:19970308T160000Z/PT8H30M

FREEBUSY;TYPE=FREE:19970308T160000Z/PT3H, 19970308T200000Z/PT1H

FREEBUSY properties within the Free/Busy Calendar Component should be
sorted in ascending order, based on start time and then end time,
with the earliest periods first.

The FREEBUSY property is optional for MIME entities conforming to this
content type. may specify more than one value, separated by
the COMMA character (ASCII decimal 44). In such cases, the FREEBUSY
property values should all be of the same STATUS (e.g., all values of
a particular STATUS listed together in a single property).

The default data type for this property is STRING.
Optionally the data type may URL, MID, or CID.

3.1.6.17 Mail Reminder PERIOD.

5.5.1.16 Last Modified

This property is identified by the property name MALARM. LAST-MODIFIED. The
property
defines an email address that is to be sent a reminder for the MIME
calendar component. A mail reminder is an electronic mail address
that will be sent a display string as an alarm for a calendar
component.

The value for the procedure reminder consists of the Run Time, or specifies the date and time that the reminder is to be executed; Snooze Time, or
the duration of time after the Run Time that the reminder is to be
dormant prior calendar information
was last revised. The property value may include multiple "date-time"
values in order to being repeated; Repeat Count, or capture the number sequence of times
that the reminder is modifications made to be repeated; Email Address, or the (RFC 822)
email address that is to
calendar information. This property may be sent specified in the reminder, Subject, event,
to-do, journal or the
textual subject of the note, free/busy calendar components. The data and the Note, or the textual reminder
string that is to time
must be sent to the email address. a UTC value.

The following property is defined by the following notation:

last-mod = "LAST-MODIFIED" ":" date-time ["," date-time] CRLF

The following is an example of this property:

MALARM:19960416T000000-0500;PT1H;24;IRS@us.gov;My Payment;
The Check Is In

LAST-MODIFIED:19960817T133000Z

The Mail! data type for this property is DATE-TIME.

5.5.1.17 Location

This property is identified by the property name LOCATION. The Reminder properties are primarily provided as a means
property defines the intended location for
allowing the capture of alarm information when accessing a event or to-do
calendar
system. It component. The property may not only be an appropriate property to send in specified within an
event or to-do request.

This property is optional for MIME entities conforming to this
content type. calendar component.

The default data type for this property is MALARM.
Optionally, defined by the data type may be URL, MID, or CID. following notation:

Dawson/Stenerson 39 41 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.6.18 Number Recurrences

This property is identified by the property name RNUM. The property
defines the number of times the calendar entry will reoccur. The

location = "LOCATION [";" paramlist] ":" locavalue CRLF

locavalue = text / url ;The value is equal to the number of recurrences that are specified by must be the
union of same type as the Recurrence Dates, Recurrence Rule, Exception Dates, and
Exception Rule property values.
;default or explicit data type.

The following is an example are some examples of this property:

RNUM:3

In the event that this value does not match the computed number of
recurrences, it will be ignored and the computed number of
recurrences will be used.

This property is optional for MIME entities conforming to this
content type.

LOCATION:Conference Room - F123, Bldg. 002

LOCATION;VALUE=URL:http://www.xyzcorp.com/~jsmith.vcf

The default data type for this property is INTEGER.

3.1.6.19 TEXT. The data type may be
reset to URL. In the case of the data type being URL, the property
value may reference a vCard object. This provides a useful mechanism
to specify a location in terms of its electronic business card.

5.5.1.18 Priority

This property is identified by the property name PRIORITY. The
property defines the priority for the MIME calendar component. event or to-do. The
value is property may
only be specified within an event or to-do calendar component. The
value is an alphanumeric. integer. A value of zero (ASCII decimal 48) specifies an
undefined priority. A value of one (ASCII decimal 49) is the highest
priority. A value of two (ASCII decimal 50) is the second highest
priority. Subsequent numbers specify a decreasing ordinal priority.

The property is specified by the following notation:

priority = "PRIORITY" ":" integer CRLF
;Default is zero

The following is an example of this property:

PRIORITY:2

This property is optional for MIME entities conforming to this
content type.

The default data type for this property is STRING.
Optionally the data type may be specified to be INTEGER.

3.1.6.20 Procedure Reminder

5.5.1.19 Related To

This property is identified by the property name PALARM. RELATED-TO. The
property
defines a procedure reminder for the MIME calendar component. A
procedure reminder is a procedure, used to represent relationships or application executable that
will be run as an alarm for a references between one
calendar component.

While this component and another. The property has many useful purposes, implementers should may only be
aware of specified in
the security implications of sending a MIME calendaring
entity containing this property. The security implications are
similar to those associated with active messages within electronic
mail. event, to-do and journal calendar components. The property value for the procedure reminder
consists of the Run Time, or the
date and time that the reminder is to persistent, globally unique identifier of another
MIME calendar component. This value would be executed; Snooze Time, or represented in a MIME
calendar component by the duration UID property.

A linked relationship can be specified by a series of time after the Run Time components that the reminder is
each, in turn, refer to their parent component. A group relationship
can be
dormant prior to being repeated; Repeat Count, or the specified by a number of times components that the reminder is to be repeated; and the Procedure Name, or the
path to the procedure all refer to be run when the reminder is executed.
Parameters are passed one
common parent component.

Changes to the procedure a calendar component referenced by concatenating to this property may
impact the related calendar component. For example, if a group event

Dawson/Stenerson 40 42 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

Procedure Name value a Question-Mark (ASCII decimal 63) followed by a
string representation of the parameters.

The following is an example of this property:

PALARM;VALUE=URL:19960415T235000-0500;PT5M;2;file:///myapps/
shockme.exe?HARD

This property is optional for MIME entities conforming to this
content type. The default data type for this property is PALARM.
Optionally, the data type may be URL, MID, or CID.

3.1.6.21 Related To

This property is identified by the property name RELATED-TO. The
property is used to represent relationships or references between
this MIME calendar component and another. The property value consists
of the persistent, globally unique identifier of another MIME
calendar component. This value would be represented in a MIME
calendar component by the UID property.

A linked relationship can be specified by a series of components that
each, in turn, refer to their parent component. A group relationship
can be specified by a number of components that all refer to one
common parent component.

Changes to a calendar component referenced by this property may
impact 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. 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.

The property is defined by the following notation:

related = "RELATED-TO" [";" paramlist] ":" relvalue CRLF

relvalue = text / url ;Value must be the same type as
;default or explicit data type

The following is an example of this property:

RELATED-TO:<jsmith.part7.19960817T083000.xyzMail@host3.com>

RELATED-TO:19960401-080045-4000F192713-0052

This property is optional for MIME entities conforming to this
content type.

The default data type for this property is STRING.
Optionally, the TEXT. The data type may be URL, MID, or CID.

3.1.6.22
reset to URL.

5.5.1.20 Recurrence Date/Times

This property is identified by the property name RDATE. This property
defines the list of date/times for a recurring MIME event, to-do or time
zone calendar component. This property may appear along with the
RRULE property to

Dawson/Stenerson 41 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997 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
date and time values is expressed in the complete representation,
basic format as specified in ISO 8601. The times can either be in local time, local time with UTC
offset or UTC based time. The number of recurring date/times If local time is used, the TIMEZONE
component must be included in the iCalendar Object, otherwise the
local time value will be interpreted relative to the time zone of the
recipient. The period values for RDATE are specified using a specific
start and a specific end basic format (period-explicit) or the period
with a specific start and a specific duration basic format (period-
start).

The property is define by the Number Recurrences property. following notation:

rdate = "RDATE" ":" rdvalue *["," rdvalue] CRLF

rdvalue = date-time / period
;Value must match the default or explicit data type

The following is an example of this property:

RDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z

This property is optional for MIME entities conforming to this
content type.

RDATE:19960403T020000Z/19960403T040000Z, 19960404T010000Z/PT3H

The default data type for this property is D-T-LIST.
Optionally, the data type may be URL; in which case the DATE-TIME. The value is the
location where a list of recurring dates can may
be found. This latter
case is a useful method for conveying dynamic recurring dates, such
as schedules, for a recurring event or to-do.

3.1.6.23 reset to PERIOD.

Dawson/Stenerson 43 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

5.5.1.21 Recurrence Rule

This property is identified by the property name RRULE. This property
defines a rule or repeating pattern for a recurring MIME calendar
component, based on the Basic Recurrence Rule Grammar of [XAPIA]. events, to-dos,
or time zone definitions. The
value for the property is a pattern specification for may be specified in the recurrence.
This event,
to-do, or time zone calendar components.

The property may appear along with value identifies the RDATE type of recursion rule. Valid
property values include HOURLY, to define specify repeating events based on
an
aggregate set interval of repeating occurrences. When they both appear in an
iCalendar Object, the recurring hour or more; DAILY, to specify repeating events are defined by the union
based on an interval of
occurrences defined by both the RDATE and RRULE. The following are
examples a day or more; WEEKLY, to specify repeating
events based on an interval of this property:

RRULE:W2 TU TH // Every other week, a week or more; MONTHLY, to specify
repeating events based on Tuesday
// an interval of a month or more; and Thursday

RRULE:D1 #10 // Daily YEARLY,
to specify repeating events based on an interval of a year or more.

The property includes property parameters that further qualify the
recurrence rule.

The INTERVAL property parameter contains a positive integer
representing how often the RRULE repeats. The default value is "1" or
every hour for 10 occurrences

RRULE:YM1 6 7 #8 // Yearly in June a HOURLY rule, every day for a DAILY rule, every week
for a WEEKLY rule, every month for a MONTHLY rule and July every year for 8
// occurrences

This
a YEARLY rule. For a HOURLY rule, the value may also be expressed as
a duration value, specifying hours and minutes for the repeat
interval. For example, PT1H30M, would represent a 1 hour and 30
minute repeat interval.

The UNTIL property parameter defines a date-time value which bounds
the RRULE. If not present, and the COUNT property parameter is optional for MIME entities conforming also
not present, the RRULE is considered to this
content type. repeat forever.

The data type for this COUNT property is parameter defines the number of occurrences at
which to bound the RRULE.

3.1.6.24 Resources This property parameter is identified by ignored if the
UNTIL property name RESOURCES. This parameter is also present.

The BYDAY property defines parameter specifies a COMMA character (ASCII
decimal 44) separated list of days of the equipment week; MO, indicates Monday;
TU, indicates Tuesday; WE, indicates Wednesday; TH, indicates
Thursday; FR, indicates Friday; SA, indicates Saturday; SU, indicates
Sunday.

Each of these parameter values may also be preceded by a positive
(+n) or resources needed in negative (-n) integer. If present, this indicates the MIME
calendar component.

Some nth
occurrence of the values that specific day within the property may have include MONTHLY or YEARLY RRULE.
For example, within a MONTHLY rule, +1MO (or simply 1MO) represents
the following:

Some Possible

Dawson/Stenerson 42 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

Property Values

CATERING

CHAIRS

COMPUTER PROJECTOR

EASEL

OVERHEAD PROJECTOR

SPEAKER PHONE

TABLE

VCR

VIDEO PHONE

VEHICLE

The following is an example of this property:

RESOURCES:EASEL;PROJECTOR;VCR

This property is optional for MIME entities conforming to this
content type. The default data type for this property is STRING-LIST.
The data type may alternatively be specified to be STRING.

3.1.6.25 Response Sequence Number

This property is identified by first Monday within the property name RESPONSE-SEQUENCE.
This property defines month, whereas -1MO represents the instance last
Monday of the MIME calendar component in
a revision sequence of responses. This month.

The BYMONTHDAY property is needed to properly
handle the receipt and processing of parameter specifies a sequence COMMA character (ASCII
decimal 44) separated list of MIME calendar
components that have been delivered out days of order. Such is the case
for store-and-forward based transports. When a response month. Valid values are 1
to an
original MIME calendaring entity is created its sequence number is
zero 31 or -31 to -1.

The BYYEARDAY property parameter specifies a COMMA character (ASCII
decimal 48). It is incremented each time it is revised.
The following is an example 44) separated list of this property:

RESPONSE-SEQUENCE:1

This property is optional for MIME entities conforming days of the year. Valid values are 1 to this
content type. The data type for this property is INTEGER.

Dawson/Stenerson 43 44 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.6.26 Sequence Number

This property is identified by the property name SEQUENCE. This
property defines

366 or -366 to -1. For example, -1 represents the instance last day of the MIME calendar component in
year (December 31st).

The BYSETPOS property parameter specifies a
sequence COMMA character (ASCII
decimal 44) separated list of revisions. This property is needed values which corresponds to properly handle the
receipt and processing 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 property parameter. For example "the
last work day of the month" could be represented as:

RRULE;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1:MONTHLY

The BYWEEKNO property parameter specifies a sequence comma separated list of MIME calendar components that
have been delivered out
weeks of order. Such is the case for store-and-
forward based transports. When year. Valid values are 1 to 52. This corresponds to
weeks according to week numbering as defined in [ISO 8601]. That is,
a MIME calendaring entity is created week as "A seven day period within a calendar year, starting on a
Monday and identified by its sequence ordinal number is zero (ASCII decimal 48). It is incremented
each time it is revised by within the OWNER and/or ORGANIZER. The following year; the
first calendar week of the year is an example the one that includes the first
Thursday of this property:

SEQUENCE:1 that year." This property parameter is optional only valid for MIME entities conforming to this
content type.
YEARLY rules.

The data type for this property is INTEGER.

3.1.6.27 Start Date/Time

This BYMONTH property is identified by parameter specifies a comma separated list of
months of the year. Valid values are 1 to 12.

The WKST property name DTSTART. This
property defines parameter specifies the date and time that day on which the calendar component will
start. The date workweek
starts. Valid values are MO, TU, WE, TH, FR, SA and time SU. This is
significant when a WEEKLY RRULE has an interval greater than 1. The
default value is expressed in the complete
representation, basic format as MO.

If two different Byxxx property parameters are specified in ISO 8601. The time can
either be in local or UTC based time. Alternatively, within the value may be
a duration of time, expressed in
RRULE, the ISO 8601 format as specified in
section 3.1.3.8. In this case, recurrence occurrence must meet both criteria.

If Byxxx property parameter values are found which are beyond the start
available scope (ie, BYMONTHDAY=-30 in February), they are simply
ignored. If a positive range limit is relative to another MIME
calendar component specified by beyond the RELATED-TO property. Events may
have available scope, it
will be interpreted as -1. Likewise, if a start date/time but no end date/time. In that case, negative range limits
beyond the event
does not take up any time. available scope, it will be interpreted as +1.

The following is an example of this
property:

DTSTART:19960401T235959-0600

This RRULE property is optional for MIME entities conforming requires referencing the DTSTART, DTEND or
DURATION properties in the iCalendar object to this
content type. The default data type for this property is DATE-TIME.
Optionally, calculate the data type may be DURATION.

3.1.6.28 Status

This property is identified by Event or
To-do instances.

The DTSTART and DTEND pair or DTSTART and DURATION pair, specified
within the property name STATUS. This
property iCalendar object defines the status associated first instance of the
recursion. When used with a recurrence rule, the MIME calendar
component. This property can only DTSTART and DTEND
properties must be used when specified in local time and the ATTENDEE property
is either not supported or not needed. The following is an example appropriate set of
this property:

STATUS:TENTATIVE

The property can
TIMEZONE components must be included. For detail on the usage of the
TIMEZONE component, see the Time Zone Calendar Component definition.

Any duration associated with the iCalendar Object applies to all
members of the generated recursion. Any modified duration for
specific recurrences would have to be explicitly specified using the following values:

Description Property
RDATE property.

Dawson/Stenerson 44 45 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

Value

Indicates to-do ACCEPTED
was accepted

Indicates event NEEDS ACTION
or to-do
requires action

Indicates event SENT
or to-do was
sent out.

Indicates event TENTATIVE
is tentatively
accepted

Indicates event CONFIRMED
is confirmed

Indicates event DECLINED
or to-do has
been declined

Indicates to-do COMPLETED
has been
completed

Indicates event DELEGATED
or to-do has
been delegated

Indicates the CANCELED
event or to-do
has been
canceled and/or
this attendee
has been
removed from
the list of
attendees.

The default value for this property is NEEDS ACTION.

This property is required defined by the following notation:

rrule = "RRULE" [rparamlist] ":" rvalue CRLF

rparamlist = rparam / rparamlist ";" rparam / paramlist
/ paramlist ";" rparam
/ paramlist ";" rparamlist ";" rparam

rparam = "UNTIL" "=" enddate
/ "COUNT" "=" interval
/ "INTERVAL" "=" rinterval
/ "BYDAY" "=" bdweekdaylist
/ "BYMONTHDAY" "=" bmdaylist
/ "BYYEARDAY" "=" bydaylist
/ "BYSETPOS" "=" bsplist
/ "BYWEEKNO" "=" bwdaylist
/ "BYMONTH" "=" bmlist
/ "WKST" "=" weekday
/ "X-" word "=" word

rvalue = "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY"

rinterval = interval ; For any rvalue
/ duration ; Only for MIME entities containing a to-do
calendar component conforming rvalue = HOURLY

DIGIT =<any ASCII decimal digit> ;0-9

digits = 1*DIGIT

interval = digits

enddate = date ;A UTC value

plus = "+"

minus = "-"

ordmoday = 1*2digits ;1 to this content type. This property is
optional for MIME entities containing an event calendar component
conforming 31

ordwk = 1*2digits ;1 to this content type. The data type for this property is
STRING. 52

ordyrday = 1*3digits ;1 to 366

daynumber = (plus / minus) ordmoday

weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" >

bdweekdaynum = [daynumber] weekday

bdweekdaylist = bdweekdaynum / bdweekdaynum "," *(bdweekdaynum)

bmposday = [plus] ordmoday

bmnegday = minus ordmoday

Dawson/Stenerson 45 46 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

3.1.6.29 Summary

This property is identified by the property name SUMMARY. This
property defines a short summary or subject of the MIME calendar
component. The following is an example

bmdaylist = bmposday *("," bmposday / bmnegday)
/ bmnegday *("," bmnegday / bmposday)

byposday = [plus] ordyrday

bynegday = minus ordyrday

bydaylist = byposday *("," byposday / bynegday)
/ bynegday *("," bynegday / byposday)

bsplist = byposday *("," byposday / bynegday)
/ bynegday *("," bynegday / byposday)

bwposday = [plus] ordwk

bwnegday = minus ordwk

bwdaylist = bwposday *("," bwposday / bwnegday)
/ bwnegday *("," bwnegday / bwposday)

bmposmon = 1*2digits ;1 to 12

bmlist = bmposmon *("," bmposmon)

Examples of this property:

SUMMARY:Department Party

This property is required for MIME entities conforming to this
content type. The data type include the following. Daily for this property is STRING.

3.1.6.30 Time Transparency

This property is identified by 10
occurrences:

RRULE;COUNT=10:DAILY

Daily until 12/24/94:

RRULE;UNTIL=19941224T000000Z:DAILY

Every other day - forever:

RRULE;INTERVAL=2:DAILY

Every 10 days, 5 occurrences:

RRULE;COUNT=5;INTERVAL=10:DAILY

Weekly for 10 occurrences

RRULE;COUNT=10:WEEKLY

Weekly until 12/24/94

RRULE;UNTIL=19941224T000000Z:WEEKLY

Every other week - forever:

RRULE;INTERVAL=2;WKST=SU:WEEKLY

Weekly on Tuesday and Thursday for 5 weeks:

Dawson/Stenerson 47 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

RRULE;INTERVAL=5;WKST=SU;BYDAY=TU,TH:WEEKLY

Every other week on Monday, Wednesday and Friday until 12/24/94:

RRULE;INTERVAL=2;WKST=SU;BYDAY=MO,WE,FR;=UNTIL=19941224T000000Z:
WEEKLY

Every other week on Tuesday and Thursday, for 8 occurrences:

RRULE;INTERVAL=2;WKST=SU;COUNT=8;BYDAY=TU,TH:WEEKLY

Monthly on the property name TRANSP. This
property defines whether 1st Friday for ten occurrences:

RRULE;COUNT=10;BYDAY=1FR:MONTHLY

Monthly on the event is transparent to free time
searches. The value of this property is a number. A value of zero
(ASCII decimal 48) guarantees that 1st Friday until 12/24/94:

RRULE;UNTIL=19941224T000000Z;BYDAY=1FR:MONTHLY

Every other month on the entry will blocks time 1st and
will be factored into a free time search. A value last Sunday of one (ASCII
decimal 49) specifies that the entry will not block time and will not
be factored into a free time search. Any values greater than _1_ will
provide implementation specific transparency semantics. Some
implementations may treat values greater than one as non-blocking or
transparent events. Other implementations may use month for
10occurrences:

RRULE;COUNT=10;BYDAY=1SU,-1SU:MONTHLY

Monthly on the numeric value second to provide a layering last Monday of levels the month for 6 months:

RRULE;COUNT=6;BYDAY=-2MO:MONTHLY

Monthly on the third to the last day of transparency. The default value is
zero (ASCII decimal 48), the event is not transparent month, forever:

RRULE;BYMONTHDAY=-3:MONTHLY

Monthly on the 2nd and will block
free time searches. The following is an example 15th of this property:

TRANSP:0

This property is optional the month for MIME entities conforming to this
content type. The data type 10 occurrences:

RRULE;COUNT=10;BYMONTHDAY=2,15:MONTHLY

Monthly on the first and last day of the month for this property is INTEGER.

3.1.6.31 Uniform Resource Locator

This property 10 occurrences:

RRULE;COUNT=10;BYMONTHDAY=1,-1:MONTHLY

Every 18 months on the 10th thru 15th of the month for 10
occurrences:

RRULE;COUNT=10;INTERVAL=18;BYMONTHDAY=10,11,12,13,14,15:MONTHLY

Monthly on the second to the last day for 5 months. So, if the start
date is identified by August 1996, the property name URL. This property
defines a Uniform Resource Locator event would repeat on 8/30/96, 9/29/96,
10/30/96, 11/29/96, and 12/30/96:

RRULE;COUNT=5;BYMONTHDAY=-2:MONTHLY

Yearly in June and July for an 10 occurrences:

RRULE;COUNT=10;BYMONTH=6,7:YEARLY

Dawson/Stenerson 48 Expires September 1997

Internet location that can
be used to obtain real-time information associated with Draft C&S Core Object Specification March 26, 1997

Every other year on January, February, and March for 10 occurrences:

RRULE;COUNT=10;INTERVAL=2;BYMONTH=1,2,3:YEARLY

Every 3rd year on the MIME
calendar component. Valid values 1st, 100th and 200th day for this property are 10 occurrences:

RRULE;COUNT=10;INTERVAL=3;BYYEARDAY=1,100,200:YEARLY

Every 20th Monday of the year, forever:

RRULE;BYDAY=20MO:YEARLY

Monday of Week No. 20, forever:

RRULE;BYWEEKNO=20;BYDAY=MO:YEARLY

Every Thursday in March, forever:

RRULE;BYDAY=TH;BYMONTH=3:YEARLY

Every Thursday, but only in the summer, forever:

RRULE;BYDAY=TH;BYMONTH=6,7,8:YEARLY

Every Friday the 13th, forever:

RRULE;BYDAY=FR;BYMONTHDAY=13:MONTHLY

The first Saturday that follows the first Sunday of the month,
forever:

RRULE;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13:MONTHLY

Every four years, the first Tuesday after a string
conforming to [RFC 1738]. Monday in November,
forever (U.S. Election day):

RRULE;INTERVAL=4;BYDAY=TU;BYMONTHDAY=7,8,9,10,11,12,13:YEARLY

The following is an example 3rd instance into the month of this
property:

URL:http://abc.com/pub/calendars/jsmith/mytime.or3

This property is optional any of Tuesday, Wednesday or
Thursday, for MIME entities conforming the next 3 months:

RRULE;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3:MONTHLY

The 2nd to this
content type. last weekday of the month"

RRULE;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2:MONTHLY

The data type for this property is URL.

3.1.6.32 Unique Identifier TEXT.

5.5.1.22 Resources

This property is identified by the property name UID. RESOURCES. This
property defines a persistent, globally unique identifier associated with the
MIME equipment or resources needed for the event or
to-do. The property value is an arbitrary text. The property may only

Dawson/Stenerson 49 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

be specified in the event or to-do calendar component. Some examples of forms of unique identifiers
would include ISO 9070 formal public identifiers (FPI), X.500
distinguished names, machine-generated _random_ numbers with More than one
resource may be specified as a
statistically high likelihood list of being globally unique and Uniform

Dawson/Stenerson 46 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

Resource Locators (URL). If an URL is specified, it is suggested that resources separated by the URL reference a service which can provide an updated version of
COMMA character (ASCII decimal 44).

The property is defined by the MIME calendar component. following notation:

resource = "RESOURCES" [";" paramlist] ":" resvalist CRLF

resvalist = resvalue / resvalue "," resvalist

resvalue = "CATERING" / "CHAIRS" / "COMPUTER PROJECTOR"
/ "EASEL" / "OVERHEAD PROJECTOR" / "SPEAKER PHONE"
/ "TABLE" / "TV" / "VCR" / "VIDEO PHONE" / "VEHICLE"
/ word

The following is an example of this property:

UID:19960401-080045-4000F192713-0052

This property is an important method for group scheduling
applications to match calendar entities with later modification or
deletion requests. Calendaring and scheduling applications that do
not generate this property in MIME calendar components may be
limiting their interoperability with other group scheduling
applications.

This property is optional for MIME entities conforming to this
content type.

RESOURCES:EASEL,PROJECTOR,VCR

The default data type for this property is STRING.
Optionally, TEXT.

5.5.1.23 Response Sequence Number

This property is identified by the data type property name RESPONSE-SEQUENCE.
This property defines the revision sequence of the calendar
component. The property may only be URL, MID, specified in an event, to-do,
journal or CID.

3.1.6.33 Non-standard Properties

The MIME Calendaring and Scheduling Content Type provides a _standard
mechanism for doing non-standard things_. free/busy calendar component. This extension support property is
provided for implementers needed to _push the envelope_ on
properly handle the existing
version receipt and processing of the specification. Extension properties are specified by
property and/or property parameter names a sequence of MIME
calendar components that have the initial sub-
string been delivered out of X- (the two character sequence: Capital X character
followed by the Dash character). It order. Such is recommended that vendors
concatenate onto this sentinel an added short sub-string to identify
the vendor. This will facilitate readability case for store-and-forward based transports. The first response
to an a request is created with response sequence number of "0"
(ASCII decimal 48). If the extensions and
minimize possible collision of names between different vendors. User
agents that support this content type are expected to value is non-zero, it must be able to
parse the extension properties and specified.
It is incremented each time another reply is sent.

The property parameters but may ignore
them. is defined by the following notation:

respseq = "RESPONSE-SEQUENCE" ":" integer CRLF
;Default is "0".

The following might be the ABC vendor's extension for is an audio-
clip form example of subject this property:

X-ABC-MMSUBJ;TYPE=WAVE; VALUE=URL: http://load.noise.org/mysubj.wav

At present, there is no registration authority for names of extension
properties and property parameters.

RESPONSE-SEQUENCE:1

The data type for this property is STRING. Optionally, INTEGER.

5.5.1.24 Sequence Number

This property is identified by the data type may be any property name SEQUENCE. This
property defines the revision sequence of the other valid
data types.

3.2 Formal Definition calendar component used
in a request. The following modified Backus-Naur Notation (BNF) property may only be specified in an event, to-do,
journal or free/busy calendar component. This property is provided needed to
assist developers in building parsers for
properly handle the properties receipt and processing of a sequence of this MIME
content type..

This syntax
calendar components that have been delivered out of order. Such is written according to
the form described in RFC
822,but it references just this small subset of RFC 822 literals:

CR = <ASCII CR, carriage return> ; ( 15, 13.)

LF = <ASCII LF, linefeed> ; ( 12, 10.) case for store-and-forward based transports. The first request is

Dawson/Stenerson 47 50 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

CRLF = CR LF

SPACE = <ASCII SP, space> ; ( 40, 32.)

HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)

All literal property names are valid as upper, lower, or mixed
case.

ws = 1*(SPACE / HTAB)

; _whitespace,_ one or more spaces or tabs

wsls = 1*(SPACE / HTAB / CRLF)

; whitespace

created with line separators

value a sequence number of "0" (ASCII decimal 48). It is
incremented each time the ORGANIZER or OWNER issues a revision to the
request.

The property is defined by the following notation:

sequence = 7bit / 8bit / quoted-printable / base64

; "SEQUENCE" ":" integer CRLF
;Default is "0".

The value must following is an example of this property:

SEQUENCE:1

The data type for this property is INTEGER.

5.5.1.25 Status

This property is identified by the property name STATUS. This
property defines the overall status for the calendar component. This
property may only be specified in the encoding type event and to-do calendar
components. When specified in an event calendar component, the
property is used to specify the general consensus for the
; meeting.
The property value.

7bit = <7bit us-ascii printable chars, excluding CR LF>

8bit = <MIME RFC 2045 8-bit text>

quoted-printable = <MIME RFC 2045 quoted-printable text>

base64 = <MIME RFC 2045 base64 text>

; may only be specified in the end of to-do calendar component
when the text ATTENDEE property is marked with two CRLF sequences

; this results in one blank line before not specified. For group scheduled
events and to-dos, the start of status is specified on an individual basis in
the next

; ATTENDEE property.

The property

word = <any printable 7bit us-ascii except []=:., >

vcal_file = [wsls] vcal [wsls]

vcal = _BEGIN_ [ws] _:_ [ws] _VCALENDAR_ [ws]
1*CRLF

calprop calentities [ws] *CRLF

_END_ [ws] _:_ [ws] _VCALENDAR_ [ws] 1*CRLF

calentities = calentities *CRLF calentity

/ calentity

calentity = evententity

/ todoentity

Dawson/Stenerson 48 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

evententity = _BEGIN_ [ws] _:_ [ws] _VEVENT_ [ws] 1*CRLF

entprops [ws] *CRLF

_END_ [ws] _:_ [ws] _VEVENT_ [ws] 1*CRLF

todoentity = _ _
BEGIN [ws] _:_ [ws] _VTODO_ [ws] 1*CRLF

entprops [ws] *CRLF

_END_ [ws] _:_ [ws] _VTODO_ [ws] 1*CRLF

calprops = calprops *CRLF calprop

/ calprop

calprop is defined by the following notation:

status = _PROFILE_

[parms] _:_ value CRLF

/ _DAYLIGHT_

[params] _:_ value CRLF

/ _CALENDAR_

[params] _:_ _GREGORIAN_ "STATUS" [";" paramlist] ":" statvalue CRLF

statvalue = "NEEDS ACTION" ;Indicates to-do needs action.
/ _GEO_

[params] _:_ value CRLF "COMPLETED" ;Indicates to-do completed
/ _PRODID_

[params] _:_ value CRLF "TENTATIVE" ;Indicates event is being
;tentatively scheduled
/ _TZ_

[params] _:_ value CRLF "CONFIRMED" ;Indicates event is definite
/ _VERSION_ _:_ _1.0_ CRLF

; "CANCELLED" ;Indicates event was canceled

The VERSION following is an example of this property:

STATUS:TENTATIVE

The data type for this property is TEXT.

5.5.1.26 Summary

This property is identified by the property name SUMMARY. This
property defines a short summary or subject for the calendar
component. The property MUST appear may only be specified in the MIME Calendar
; Object.

entprops event, to-do and
alarm calendar component.

The property is defined by the following notation:

summary = entprops *CRLF entprop

/ entprop

entprop = [ws] simprop

[params] _:_ value "SUMMARY" [";" paramlist] ":" text CRLF

/ [ws] _AALARM_

Dawson/Stenerson 49 51 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

[params] _:_ aalarmparts CRLF

/ [ws] _CATEGORIES_

[params] _:_ 1*catvals CRLF

/ [ws] _CLASS_

[params] _:_ classvals CRLF

/ [ws] _DALARM_

[params] _:_ dalarmparts CRLF

/ [ws] _EXDATE_

[params] _:_ xdatevals CRLF

/ [ws] _MALARM_

[params] _:_ malarmparts CRLF

/ [ws] _PALARM_

[params] _:_ palarmparts CRLF

/ [ws] _RDATE_

[params] _:_ rdatevals CRLF

/ [ws] _RESOURCES_

[params] _:_ 1*resvals CRLF

/ [ws] _STATUS_

[params] _:_ statvals CRLF

simprop = _ATTACH_ / _ATTENDEE_ / _DCREATED_ / _COMPLETED_

/ _DESCRIPTION /
_ _DTSTART_ / _DUE_ / _DTEND_ / _EXRULE_

/ _LAST-MODIFIED_ / _LOCATION_ / _RNUM_ / _PRIORITY_

/ _RELATED-TO_ / _RESPONSE-SEQUENCE_ / _RRULE_

/ _SEQUENCE_ / _SUMMARY_ / _TRANSP_ / _URL_ / _UID_

/ _X-_ word

aalarmparts

The following is an example of this property:

SUMMARY:Department Party

The data type for this property is TEXT.

5.5.1.27 Time Transparency

This property is identified by the property name TRANSP. This
property defines whether an event is transparent or not to free/busy
time searches. This property may only be specified in an event
calendar component.

The property is specified by the following notation:

transp = 0*3(strnosemi _;_) strnosemi

; runTime, snoozeTime, repeatCount, audioContent

Dawson/Stenerson 50 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

catvals "TRANSP" [";" paramlist] ":" transvalue CRLF

transvalue = _APPOINTMENT_ / _BUSINESS_ / _EDUCATION_ / _HOLIDAY_

/ _MEETING_ / _MISCELLANEOUS_ / _NOT-IN-OFFICE_

/ _NON-WORKING-HOURS_ / _PERSONAL_ / _PHONE CALL_

/ _SICK DAY_ / _SPECIAL OCCASION_ / _TRAVEL_

/ _VACATION_ / _X-_ word / "BUSY" ;Opaque/blocks on free/busy searches
;Default value

classvals = _PUBLIC_ is BUSY
/ _PRIVATE_ "OUT" ;Opaque/blocks on free/busy searches
/ _CONFIDENTIAL_ "PRIVATE" ;Opaque/blocks on free/busy searches
/ _X-_ word "CONFIDENTIAL" ;Opaque/blocks on free/busy searches
/ value

dalarmparts = 0*3(strnosemi _;_) strnosemi

; runTime, snoozeTime, repeatCount, displayString

malarmparts = 0*5(strnosemi _;_) strnosemi

; runTime, snoozeTime, repeatCount, addressString,
; subjectstring, noteString

palarmparts = 0*3(strnosemi _;_) strnosemi

; runTime, snoozeTime, repeatCount, procedureName

rdatevals = 1*value

; One "TRANSPARENT" ;Transparent on free/time searches

The following is an example of this property for an event that is
transparent or more date/time values

resvals = _CATERING_ / _CHAIRS_ / _EASEL_ / _PROJECTOR_ / _VCR_

/ _VEHICLE_ / _X-_ word / value

statvals = _ACCEPTED_ / _NEEDS ACTION_ / _SENT_ / _TENTATIVE_

/ _CONFIRMED_ / _DECLINED_ / _COMPLETED_ / _DELEGATED_

/ _X-_ word / value

params = _;_ [ws] paramlist

paramlist = paramlist [ws] _;_ [ws] param

/ param

param = _TYPE_ [ws] _=_ [ws] ptypeval

/ [_VALUE_ [ws] _=_ [ws]] pvalueval

/ [_ENCODING_ [ws] _=_ [ws]] pencodingval

/ _CHARSET_ [ws] _=_ [ws] charsetval

Dawson/Stenerson 51 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

/ _DATATYPE_ [ws] _=_ [ws] dtypeval

/ _LANGUAGE_ [ws] _=_ [ws] langval

/ _MEMBER_ [ws] _=_ [ws] <RFC 822 address specification>

/ _ROLE_ [ws] _=_ [ws] roleval

/ _STATUS_ [ws] _=_ [ws] statuval

/ _X-_ word [ws] _=_ [ws] word

/ knowntype

ptypeval = knowntype / attendtype / _X-_ word

knowntype = _ _
BASIC / _WAVE_ / _X-_ word / value

attendtype = _INDIVIDUAL_ / _GROUP_ / _RESOURCE_ / _UNKNOWN_

pvalueval = _INLINE_ / _URL_ / _CONTENT-ID_ / _CID_ /

/ _MESSAGE-ID_ / _MID_ / _X-_ word

pencodingval = _7BIT_ / 8BIT
_ _ / _QUOTED-PRINTABLE_ / _BASE64_

/ _X-_ word

charsetval = <a character set string as defined 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:BUSY

The data type for this property is TEXT.

5.5.1.28 Time Zone Name

This property is identified by the property name TZNAME. This
property specifies the customary designation for a time zone
descripiton. This property may only be specified in RFC 2046>

dtypeval = _AALARM_ / _BOOLEAN_ / _CID_ / _DALARM_ / _DATE-TIME_

/ _DST-RULE_ / _D-T-LIST_ / _DURATION_ / _FLOAT_

/ _FLOAT-LIST_ _
/ INTEGER_ / _INTEGER-LIST_ / _MALARM_

/ _MID / _
_ PALARM_ / RFC822-ADDRESS
_ _ / _RRULE_

/ _STRING_ / _STRING-LIST_ / _TIME-OFFSET_ / _URL_

/ _X-_ word

langval = <a language string as the Time Zone
Calendar Component.

This property is defined in RFC 1766>

roleval = _ATTENDEE_ / _ORGANIZER_ / _OWNER_ / _X-_ word

statusval = _ACCEPTED_ / _ _ /
NEEDS ACTION _SENT_ / _TENTATIVE_

/ _CONFIRMED_ / _DECLINED_ / _COMPLETED_ / _DELEGATED_

/ _X-_ word

strnosemi by the following notation:

tzname = *(*nonsemi (_\;_ / _\_ CRLF)) *nonsemi "TZNAME" [";" paramlist] ":" text CRLF

The following are examples of this property:

TZNAME: EST

TZNAME: PDT

The data type for this property is TEXT.

Dawson/Stenerson 52 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

; To include a semicolon in this string, it must be escaped

; with a _\_ character.

nonsemi = <any non-control ASCII except _;_>

3.3 Basic Recurrence Rule Grammar

The specification of recurring events can be simplified

5.5.1.29 Time Zone Offset

This property is identified by the use of
a grammar or rule notation. property name TZOFFSET. This specification makes use of
property specifies the Base
Recurrence Rule Grammar offset from the [XAPIA].

A recurrence rule is UTC for a string or clear-text encoding of time zone. This property
may only be specified in a recurrence
specification. Time Zone Calendar Component. A recurrence rule Time Zone
Calendar Component must include this property. The property value is composed of several components. A
rule begins with
a frequency which describes signed numeric indicating the type number of repeating
event (e.g., daily, weekly, etc.). This is followed by an interval
which indicates how often the frequency repeats (i.e., daily, every
third day, etc.). This can be followed by optional frequency modifier
information hours and either an end date possibly minutes
from UTC. Positive numbers represents time zones east, or a duration.

Below ahead of
UTC. Negative numbers represents time zones west of, or behind UTC.

The property is defined by the form following notation:

tzoffset = "TZOFFSET" ":" utc-offset CRLF

The following are examples of a typical rule. This example causes events to be
generated every other week on Tuesday and Thursday, this property:

TZOFFSET:-0500

TZOFFSET:+0530

The data type for 8
occurrences:

W2 TU TH #4

Where, W this property is the Frequency, 2 UTC-OFFSET.

5.5.1.30 Time Zone Transition Time

This property is identified by the Interval, TU and TH are property name TZTRANS. This
property specifies the
optional Frequency Modifiers, and #4 time of day when a time zone transitions to
the specified time observance (e.g., into daylight savings time).

The property is defined by the Duration. following notation:

tztrans = "TZTRANS" ":" time CRLF

The basic recurrence rule grammar supports six types following are examples of repetition. this property:

TZTRANS:020000

The six types follow data type for this property is TIME.

5.5.1.31 Uniform Resource Locator

This property is identified by the same form property name URL. This property
defines a Uniform Resource Locator (URL) associated with only the frequency name and
optional modifier information changing from one type of frequency to
iCalendar Object. This property may be specified in the next.

3.3.1 Daily Rule event, to-do,
journal, free/busy, and alarm calendar components.

The daily rule property is defined by the following notation:

url = "URL" ":" url CRLF

The following is used for specifying repeating events based on an
interval example of a day or more. These can range from every day to every
200th day and beyond. this property:

URL:http://abc.com/pub/calendars/jsmith/mytime.or3

The daily rule begins with the letter D
followed by an interval (representing days) and an optional duration
or end date.

Some examples follow:

Daily data type for 10 occurrences:
D1 #10

Daily until 12/24/94:
D1 19941224T000000Z

Every other day - forever:
D2 #0 this property is URL.

Dawson/Stenerson 53 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

Every 10 days, 5 occurrences:
D10 #5

3.3.2 Weekly Rule

The weekly rule

5.5.1.32 Unique Identifier

This property is used for specifying repeating events based on an
interval of a week or more. The basic weekly rule has the same form
as identified by the daily rule except that property name UID. This property
defines the rule begins with a W and can
contain an optional list of weekdays persistent, globally unique identifier for the events are generated on. For
weekly rules, calendar
component. The property may be specified in the interval represents weeks. Some examples follow:

Weekly for 10 occurrences:
W1 #10

Weekly until 12/24/94:
W1 19941224T000000Z

Every other week - forever:
W2 #0

Weekly on Tuesday and
Thursday for 5 weeks:
W1 TU TH #5

Every other week on Monday Wednesday event and Friday until 12/24/94:
W2 MO WE FR 19941224T000000Z

3.3.3 Monthly Rule to-do
calendar components.

The monthly rule property is defined by the following notation:

uid = "UID" [";" paramlist] ":" text CRLF

The following is used for specifying repeating events base on an
interval of a month or more. There are two types example of monthly
recurrence rules. One this property:

UID:19960401-080045-4000F192713-0052

This property is an important method for by-position group scheduling
applications to match requests with later replies, modifications or
deletion requests. Calendaring and one for by-day. The by-
position rule allows weekdays scheduling applications that do
not generate this property in the month to be specified in
relation to their occurrence in the month. An example would be to
specify the third Sunday of the month or the last Friday of the
month. An occurrence specifier event and to-do calendar components may
be used in monthly by-position
rules. limiting their interoperability with other group scheduling
applications.

The occurrence specifiers control which occurrence of a
weekday in data type for this property is TEXT.

5.5.1.33 Non-standard Properties

The MIME Calendaring and Scheduling Content Type provides a month an event occurs on:

1+, 2+, ... 5+ "standard
mechanism for the first occurrence, second, ...fifth
occurrence of the month.

1-, 2-, ... 5- doing non-standard things". This extension support is
provided for the last occurrence, second implementers to last occurrence,
etc.

A 2+ FR SA would indicate "push the second occurrence envelope" on the existing
version of Friday and
Saturday in the month. A 1- MO would indicate specification. Extension properties are specified by
property and/or property parameter names that have the first occurrence prefix text of
Monday working from
"X-" (the two character sequence: LATIN CAPITAL LETTER X character
followed by the end of HYPEN-MINUS character). It is recommended that
vendors concatenate onto this sentinel another short prefix text to
identify the month backwards (i.e., vendor. This will facilitate readability of the last
occurrence). A 2- MO would
extensions and minimize possible collision of names between different
vendors. User agents that support this content type are expected to
be the second able to parse the last Monday of extension properties and property parameters but
may ignore them.

The property is defined by the
month.

A by-day rule allows actual day numbers to following notation:

extension = "X-" [vendorid] word [";" paramlist] ":" value

vendorid = 1*char "-" ;Vendor identification prefix text

The following might be specified such the ABC vendor's extension for an audio-clip
form of subject property:

X-ABC-MMSUBJ;TYPE=WAVE; VALUE=URL: http://load.noise.org/mysubj.wav

At present, there is no registration authority for names of extension
properties and property parameters. The data type for this property

Dawson/Stenerson 54 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

is TEXT. Optionally, the data type may be any of the other valid data
types.

5.6 Complete Format Definition

The following modified Backus-Naur Notation (BNF) is provided to
assist developers in building parsers for the properties of this
content type.

CHAR = <Any character in the selected character set>
DIGIT = <Any ASCII decimal digit> ;0-9
CTL = <Any control character in the selected character set>
CR = <ASCII CR, carriage return, ASCII decimal 13>
LF = <ASCII LF, line feed, ASCII decimal 10>
SPACE = <ASCII SP, space, ASCII decimal 32>
HTAB = <ASCII HT, horizontal tab, ASCII decimal 9>
CLRF = CR LF
LWSP-char = SPACE / HTAB ;Semantics equals SPACE
linear-white-space = 1*(CRLF LWSP-char)
;Semantics is SPACE CRLF, which indicates folding
WORD = ATOM / quoted-string
quoted-string = <"> *(qtext/quoted-pair) <"> ; Regular qtext or
; quoted chars.
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including linear-white-space>
quoted-pair ="\" CHAR ; may quote any char
ATOM = 1*<any CHAR except specials, SPACE and CTLs>

;
;Definition of a line of content information
;
contentline = [group "."] name [";" paramlist] ":" value CRLF
;Folding permitted on content lines.

group = atom ;As defined in [RFC 822]

name = x-name / iana-name ;An iCalendar attribute/property

x-name = <The two characters "X-" or "x-" followed, with no
intervening white space, by any atom>

iana-name = <A publicly defined name, registered with IANA>

paramlist = parameter / paramlist ";" parameter

parameter = encodingparm
/ valuetypeparm ;If not present => inline value
/ charsetparm
/ languageparm
/ [parmtype "="] parmvalues

encodingparm = "encoding" "=" encodetype

Dawson/Stenerson 55 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

encodetype = "8bit" ;From [RFC 2045]
/ "7bit" ;From [RFC 2045]
/ "base64" ;From [RFC 2045]
/ "quoted-printable" ;From [RFC 2045]

valuetypeparm = "value" "=" valuetype

valuetype = "url"
/ "text"
/ "date"
/ "time"
/ "date-time"
/ "period"
/ "duration"
/ "boolean"
/ "integer"
/ "float"
/ "rfc822-address"
/ "utc-offset"
/ x-token
/ iana-value

iana-value = <A publicly defined extension value type, registered
with IANA, as specified by this document>

charsetparm = "charset" "=" charset ;As defined in [RFC 2047]

languageparm = "language" "=" language ;As defined in [RFC 1766]

parmtype = x-token / iana-ptype

iana-ptype = <A publicly defined extension parameter type,
registered with IANA, as specified by this document>

parmvalues = parmvalue / parmvalues "," parmvalue

parmvalue = x-name / iana-pvalue

iana-pvalue = <A publicly defined extension parameter value,
registered with IANA, as specified by this document>

value = url / text / date / time/ date-time / period /
/ duration / boolean / integer / float / rfc822-address
/ utc-offset / iana-value

iana-value = <A publicly defined property value data type,
registered with IANA, as the
12th day or 29th day. defined in this document>

;
;Data Types
;
url = <As defined by [RFC 1738]>

Dawson/Stenerson 54 56 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

The by-position rule begins with

text = <Any CHAR include a MP and the by-day rule begins with bare CR or a MD. The interval in monthly rules represents months. Some examples
follow:

Monthly on the 1st Friday for ten occurrences:
MP1 1+ FR #10

Monthly on the 1st Friday until 12/24/94:
MP1 1+ FR 19941224T000000Z

Every other month on the 1st and last
Sunday of the month for 10 occurrences:
MP2 1+ SU 1- SU #10

Every six months on the 2nd Monday
through Friday for 10 occurrences:
MP6 2+ MO TU WE TH FR #10

Monthly on the second last Monday of the month for 6 months:

MP1 2- MO #6

Monthly on the third to the last day of the month, forever:

MD1 3- #0

Monthly on the 2nd and 15th of the month for 10 occurrences:
MD1 2 15 #10

In the next example LD refers to _LastDay_ in bare LF but
not a monthly recurrence
rule. Monthly on the 1st and last day of the month for 10
occurrences:
MD1 1 LD #10 or MD1 1 1- #10

Every 18 months on the 10th through 15th of the month for 10
occurrences:
MD18 10 11 12 13 14 15 #10

Monthly CRLF sequence>

date-fullyear = 4DIGIT
date-month = 2DIGIT ;01-12
date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
;based on the second to the last day for 5 months. So, if the
start month/year
full-date = date-fullyear date-month date-mday
date = fulldate *["," fulldate]

date-time = date "T" time ;As specified above in date is August 1996, the event would repeat on 8/30/96,
9/29/96, 10/30/96, 11/29/96, and 12/30/96:
MD1 2- #5

3.3.4 Yearly Rule

The yearly rule is used time

dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)

dur-week = 1*DIGIT "W"
dur-day = 1*DIGIT "D"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]

duration = "P" (dur-date / dur-time / dur-week)

period-explicit = date-time "/" date-time
;ISO 8601 complete representation basic format for specifying repeating events based on an
interval of a year or more. There are two types period of yearly recurrence
rules. One for by-month and one for by-day. The by-month rule allows
specific months out time
;consisting of the year to be specified. a start and end. The by-day allows
specific days to start must be specified. In the by-month rule, the day in the
month the rule is to occur on is determined from before the initial
appointment. end.

period-start = date-time "/" duration
;ISO 8601 complete representation basic format for a period of time
;consisting of a start and duration of time.
period = period-explicit / period-start

boolean = "TRUE" / "FALSE"

integer = ["+" / "-"] *DIGIT

float = ["+" / "-"] *DIGIT ["." *DIGIT]

rfc822-address = addr-spec / [phrase] "<" addr-spec ">"

addr-spec = local-part "@" domain ;RFC 822 address
local-part = WORD *("." WORD)
domain = domain-ref *("." domain-ref)

Dawson/Stenerson 55 57 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

The by-month rule begins

domain-ref = ATOM
phrase = 1*WORD

utc-offset = time-numzone ;As defined above in time

;
;Definition of an iCalendar Object
;
icalobject = "BEGIN" ":" "VCALENDAR" CRLF
icalbody
"END" ":" "VCALENDAR" CRLF [icalobject]

;
;Definition of an iCalendar Property
;
property = [group "."] propname [";" parmlist] ":" value CRLF

propname = <any properties defined in this document>
/ iana-prop / x-token

x-token = <The two characters "X-" or "x-" followed, with a YM no
intervening white space, by any atom>

iana-prop = <A publicly defined extension property, registered
with IANA, as specified by this document>

;
;Definition of the Calendar Components and Calendar Properties
;
icalbody = calprops 1*component

calprops = [calscale] [geo] prodid [profile] [prof-version]
[source] [name] version

component = 1*(eventc / todoc / journalc / freebusyc /
/ timezonec)

;Event Component
eventc = "BEGIN" ":" "VEVENT" CRLF
*eventprop *alarmc
"END" ":" "VEVENT" CRLF

;To-do Component
todoc = "BEGIN" ":" "VTODO" CRLF
*todoprop *alarmc
"END" ":" "VTODO" CRLF

Dawson/Stenerson 58 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

;Journal Component
journalc = "BEGIN" ":" "VJOURNAL" CRLF
*jourprop
"END" ":" "VJOURNAL" CRLF

jourprop = *attach *categories [class] [created] description
/ dtstart *last-mod *related [resp-seq] [seq] [uid] *url

;Free/Busy Component
freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
*fbprop
"END" ":" "VFREEBUSY" CRLF

fbprop = *attendee [created] [duration] [dtend] [dtstart]
/ *freebusy *last-mod *related [resp-seq] [seq] [uid]
/ *url

;Alarm Component
alarmc = "BEGIN" ":" "VALARM" CRLF
*alarmprop
"END" ":" "VALARM" CRLF

alarmprop = *attach [created] [description] dtstart duration
/ *last-mod *related repeat [summary] *url

;Time Zone Component
timezonec = "BEGIN" ":" "VTIMEZONE" CRLF
*tzprop
"END" ":" "VTIMEZONE" CRLF

tzprop = [created] [daylight] [dtend] dtstart [rdate / rrule]
[tzname] tzoffset [tztrans] [uid]

;
;Definition of the by-day rule begins with a
YD. The interval in yearly rules represents years. Some examples
follow:

Yearly in June and July for 10 occurrences:
YM1 6 7 #10

Every Calendar Properties
;
calscale = "CALSCALE" ":" calvalue CRLF
calvalue = "GREGORIAN" / iana-scale
iana-scale = <Any other year on January, Feb, and March designator for 10 occurrences:
YM2 1 2 3 #10

Every 3rd year on a calendar scale
registered with IANA>

geo = "GEO" ":" geovalue CRLF
geovalue = (float ";" float )/ url

prodid = "prodid" ":" pidvalue CRLF
pidvalue = (guid-text / url)
;Any text that describes the 1st, 100th product and 200th day for 10 occurrences:
YD3 1 100 200 #10

3.3.5 Grammar

[Editor's Note: The format of this BNF will be changed to the
RFC 822 ABNF in the next version
;and that is generally assured of the draft.]

{} 0 or more

[] 0 or 1

start ::= <daily> [<enddate>] |

<weekly> [<enddate>] |

<monthlybypos> [<enddate>] |

<monthlybyday> [<enddate>] |

<yearlybymonth> [<enddate>] |

<yearlybyday> [<enddate>]

digit ::= <0|1|2|3|4|5|6|7|8|9>

digits ::= <digit> {<digits>}

enddate ::= ISO 8601_date_time value(e.g., 19940712T101530Z)

interval ::= <digits>

duration ::= #<digits>

lastday ::= LD

plus ::= +

minus ::= -

daynumber ::= <1-31> [<plus>|<minus>]| <lastday>

daynumberlist ::= daynumber {<daynumberlist>} being unique.>

Dawson/Stenerson 56 59 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

month ::= <1-12>

monthlist ::= <month> {<monthlist>}

day ::= <1-366>

daylist ::= <day> {<daylist>}

occurrence ::= <1-5><plus> | <1-5><minus>

weekday ::= <SU|MO|TU|WE|TH|FR|SA>

weekdaylist ::= <weekday> {<weekdaylist>}

occurrenceweekday ::= [<occurrence>] <weekday>

occurenceweekdaylist ::= <occurenceweekday>

{<occurenceweekdaylist>}

daily ::= D<interval> [<duration>]

weekly ::= W<interval> [<weekdaylist>] [<duration>]

monthlybypos ::= MP<interval> [<occurrenceweekdaylist>]

[<duration>]

monthlybyday ::= MD<interval> [<daynumberlist>] [<duration>]

yearlybymonth ::= YM<interval> [<monthlist>] [<duration>]

yearlybyday ::= YD<interval> [<daylist>] [<duration>]

3.3.6 Grammar Glossary

enddate Controls when a repeating event terminates. The enddate
is the last time an event can occur.

Interval Defines the frequency in which a rule repeats.

duration Controls the number of events a rule generates.

Lastday Can be used as a replacement to daynumber to indicate
the last day of the month.

daynumber A number representing a day of the month.

month

profile = "PROFILE" ": profvalue CRLF
profvalue = " component "-" action
component = "EVENT" / "TODO" / "JOURNAL" / "FREEBUSY"
/ iana-component / x-token
action = <Any IANA registered iCalendar action type.>
iana-component = <Any other component registered with IANA>

prof-version = "PROFILE-VERSION" ":" profvalue CRLF
profvalue = iana-prfver / x-token
iana-prfver = <A IANA registered iCalendar profile identifier>

source = "SOURCE" ":" url CRLF

name = "NAME" ":" text CRLF

version = "VERSION" ":" vervalue CRLF
vervalue = "2.0" / x-token

;Component Properties
attach = [group "."] "ATTACH" ":" url CRLF

attendee = [group "."] "ATTENDEE" [";" attparamlist] ":"
(rfc822-address / url) CRLF

attparamlist = attparam / attparamlist ";" attparam
/ paramlist / paramlist ";" attparam
/ paramlist ";" attparamlist ";" attparam

attparam = typeparm / roleparm / statusparm / rsvpparm
/ expectparm / memberparm

typeparm = "TYPE" "="
("INDIVIDUAL" ; An individual
/ "GROUP" ; A number representing a month group of the year.

day individuals
/ "RESOURCE" ; A number representing physical resource
/ "ROOM" ; A room resource
/ "UNKNOWN") ; Otherwise not known
;Default value is UNKNOWN

roleparm = "ROLE" "="
("ATTENDEE" ; Indicates a day regular attendee
/ "OWNER" ; Indicates owner of the year.

occurrence Controls which week event or to-do
/ "ORGANIZER" ; Indicates organizer of the month a particular weekday event occurs. or to-do
/ "DELEGATE") ; Indicates delegate to event or to-do
;Default is ATTENDEE

statusparm = "STATUS" "="
("NEEDS-ACTION" ; Indicates event or to-do needs action
/ "ACCEPTED" ; Indicates event or to-do accepted
/ "DECLINED" ; Indicates event or to-do not accepted
/ "TENTATIVE" ; Indicates event or to-do tentatively
; accepted. Status may change in the future.
/ "COMPLETED" ; Indicates to-do was completed.
; COMPLETED property has date/time completed.

Dawson/Stenerson 57 60 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

weekday A symbol representing a day of the week.

daily Defines a rule that repeats on a daily basis.

weekly Defines a rule that repeats on a weekly basis.

monthlybypos Defines a rule that repeats on a monthly basis on a
relative day and week.

monthlybyday Defines a rule that repeats on a monthly basis on

/ "DELEGATED" ; Indicateds event or to-do delegated
; to another ATTENDEE
/ "CANCELED") ; Indicates event or to-do canceled for
; ATTENDEE
;Default is NEEDS-ACTION

rsvpparm = "RSVP" "=" ("YES" / "NO")
;Default is NO

expectparm = "EXPECT" "="
("FYI" ; Indicates request is for your info
/ "REQUIRE" ; Indicates presence is required
/ "REQUEST" ; Indicates presence is requested
/ "IMMEDIATE") ; Indicates an
absolute day.

yearlybymonth Defines a rule that repeats on specific months
of the year.

yearlybyday Defines a rule that repeats on specific days of the
year.

3.3.7 Policies

1.
The duration portion of immediate response needed
;Default is FYI

memberparm = rfc822-address ; Indicates a rule defines the total number of events
the rule generates, including the first event.

2.
Information, not contained group or mailing list

categories = "CATEGORIES" [";" paramlist] ":" catvalue CRLF

catvalue = cat1value [,cat1value] / cat2value [, cat2value]

3.
If an end date and a duration is specified to-do components
cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
/ x-token / iana-word
;Used in the rule, the
recurring event ceases when the end date alarm component

class = "CLASS" [";" paramlist] ":" classvalue CRLF
classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / x-token
;Default is reached or the number
of events indicated in the PUBLIC

created = "CREATED" ":" date-time CRLF

completed = "COMPLETED" ":" date-time CRLF

daylight = "DAYLIGHT" ":" boolean CRLF
;Default value is FALSE

description = "DESCRIPTION" [";" paramlist] text CRLF

due = "DUE" ":" date-time CRLF

duration occur; whichever comes first.

4.
If the = "DURATION" ":" duration CRLF

dtstart = "DTSTART" ":" date-time CRLF

dtend = "DTEND" ":" date-time CRLF

exdate = "EXDATE" ":" date-time *["," date-time] CRLF

Dawson/Stenerson 61 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

exrule = "EXRULE" [";" rparamlist] ":" rvalue CRLF

freebusy = "FREEBUSY" [";" fbparmlist] ":" fbvalue CRLF

fbparmlist = fbparam / paramlist ";" fbparam
/ fbparam ";" fbparmlist
fbparam = fbtype / fbstatus

fbtype = "TYPE" "=" ("FREE" or an end date is not established in the rule
(e.g., D4) the event occurs twice. That "BUSY")
;Default is D4 BUSY

fbstatus = "STATUS" "="
"BUSY" ;Represents busy time interval
/ "OUT" ;Represents out-of-office, non-working
;hours, or other unavailable interval
/ "PRIVATE" ;Represents private unavailable time
/ "CONFIDENTIAL" ;Represents confidential unavailable
;time
;Default is equivalent to D4
#2.

5.
A duration of #0 means repeat this event forever.

6.
Using the occurrence specifier 5+ (e.g. 5th Friday) or 5- (e.g.
5th from last Friday) in a month that does not contain 5 weeks
does not generate an event and thus does not count against BUSY

fbvalue = period ["," period]
;Value must match default or explicit data type

last-mod = "LAST-MODIFIED" ":" date-time ["," date-time] CRLF

location = "LOCATION [";" paramlist] ":" locavalue CRLF
locavalue = text / url ;The value must be the
duration. The same applies to providing a day of the month that
does not occur in the month. For example type as the 30th
;default or 31st .

7.
The start time and date of an entry explicit data type.

priority = "PRIORITY" ":" integer CRLF
;Default is zero

related-to = "RELATED-TO" [";" paramlist] ":" relvalue CRLF
relvalue = text / url ;Value must be synchronized with one
of the repeating events defined by its recurrence rule. The
following is not allowed:

Initial Appointment Date: 7/1/94 (Friday)
Recurrence Rule: W1 MO TH #5

The following is acceptable:

Initial Appt Date: 7/1/94 (Friday)
Recurrence Rule: W1 MO FR #5 same type as
;default or explicit data type

rdate = "RDATE" ":" rdvalue *["," rdvalue] CRLF
rdvalue = date-time / period
;Value must match default or W1 #5 explicit data type

;
;Definition of recurrence rule
;rrule = "RRULE" [rparamlist] ":" rvalue CRLF

rparamlist = rparam / rparamlist ";" rparam / paramlist
/ paramlist ";" rparam
/ paramlist ";" rparamlist ";" rparam

rparam = "UNTIL" "=" enddate
/ "COUNT" "=" interval
/ "INTERVAL" "=" rinterval
/ "BYDAY" "=" bdweekdaylist
/ "BYMONTHDAY" "=" bmdaylist
/ "BYYEARDAY" "=" bydaylist

Dawson/Stenerson 58 62 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

8.
If the optional <occurrencelist> and <weekdaylist> information is
missing from a <monthlybypos> occurrence the information is
derived from the entry attributes. The <occurrence> used in the
recurring event is a count from the beginning of the month to the
entry

/ "BYSETPOS" "=" bsplist
/ "BYWEEKNO" "=" bwdaylist
/ "BYMONTH" "=" bmlist
/ "WKST" "=" weekday
/ "X-" word "=" word

rvalue = "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY"

rinterval = interval ; For any rvalue
/ duration ; Only for rvalue = HOURLY

digits = 1*digit

interval = digits

enddate = date and the <weekday> used ;A UTC value

plus = "+"

minus = "-"

ordmoday = 1*2digits ;1 to 31

ordwk = 1*2digits ;1 to 52

ordyrday = 1*3digits ;1 to 366

daynumber = (plus / minus) ordmoday

weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" >

bdweekdaynum = [daynumber] weekday

bdweekdaylist = bdweekdaynum / bdweekdaynum "," *(bdweekdaynum)

bmposday = [plus] ordmoday

bmnegday = minus ordmoday

bmdaylist = bmposday *("," bmposday / bmnegday)
/ bmnegday *("," bmnegday / bmposday)

byposday = [plus] ordyrday

bynegday = minus ordyrday

bydaylist = byposday *("," byposday / bynegday)
/ bynegday *("," bynegday / byposday)

bsplist = byposday *("," byposday / bynegday)
/ bynegday *("," bynegday / byposday)

bwposday = [plus] ordwk

Dawson/Stenerson 63 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

bwnegday = minus ordwk

bwdaylist = bwposday *("," bwposday / bwnegday)
/ bwnegday *("," bwnegday / bwposday)

bmposmon = 1*2digits ;1 to 12

bmlist = bmposmon *("," bmposmon)

resource = "RESOURCES" [";" paramlist] ":" resvalist CRLF
resvalist = resvalue / resvalue "," resvalist
resvalue = "CATERING" / "CHAIRS" / "COMPUTER PROJECTOR"
/ "EASEL" / "OVERHEAD PROJECTOR" / "SPEAKER PHONE"
/ "TABLE" / "TV" / "VCR" / "VIDEO PHONE" / "VEHICLE"
/ word

respseq = "RESPONSE-SEQUENCE" ":" integer CRLF
;Default is the day of the week the entry "0".

sequence = "SEQUENCE" ":" integer CRLF
;Default is scheduled to occur on.

9.
If the <monthlybypos> occurrence or <monthlybyday> occurrence does
not list a week day (e.g., SU or day 10) in the rule, the week day "0".

status = "STATUS" [";" paramlist] ":" statvalue CRLF

statvalue = "NEEDS ACTION" ;Indicates to-do needs action.
/ "COMPLETED" ;Indicates to-do completed
/ "TENTATIVE" ;Indicates event is established from the entry attribute information. As an example
the rule MP1 #3 used in an entry with a start date of 7/20/94
(which being
;tentatively scheduled
/ "CONFIRMED" ;Indicates event is the third Wednesday of the month) repeats definite
/ "CANCELLED" ;Indicates event was canceled

summary = "SUMMARY" [";" paramlist] ":" text CRLF

transp = "TRANSP" [";" paramlist] ":" transvalue CRLF
transvalue = "BUSY" ;Opaque/blocks on 8/17/94
which free/busy searches
;Default value is the third Wednesday BUSY
/ "OUT" ;Opaque/blocks on free/busy searches
/ "PRIVATE" ;Opaque/blocks on free/busy searches
/ "CONFIDENTIAL" ;Opaque/blocks on free/busy searches
/ "TRANSPARENT" ;Transparent on free/time searches

tzname = "TZNAME" [";" paramlist] ":" text CRLF

tzoffset = "TZOFFSET" ":" utc-offset CRLF

tztrans = "TZTRANS" ":" time CRLF

url = "URL" ":" url CRLF

uid = "UID" [";" paramlist] ":" text CRLF

extension = "X-" [vendorid] word [";" paramlist] ":" value
vendorid = 1*char "-" ;Vendor identification prefix text

Dawson/Stenerson 64 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

;End of the month.

4. grammar

6. Registration of Content Type Profiles

This section defines procedures by which usage profiles for the MIME
Calendaring and Scheduling Content Type are registered with the IANA
and made available to the Internet community. Note that non-IANA
profiles may be used by bilateral agreement, provided the associated
profile names follow the "X-" convention defined above in section
3.1.6.33.

The procedures defined here are designed to allow public comment and
review of new profiles, while posing only a small impediment to the
definition of new profiles.

Registration of a new profile is accomplished by the following steps.

4.1

6.1 Define the profile

A profile is defined by completing the following template.

To: ietf-calendar@imc.org

Subject: Registration of text/calendar MIME profile XXX

Profile name:

Profile purpose:

Profile type-subtype:

Profile special notes (optional):

Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

The explanation of what goes in each field in the template follows.

Profile name: The name of the profile as it will be generally
referred to in public. This name is required in the profile.

Dawson/Stenerson 59 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

Profile purpose: The purpose of the profile (e.g., to schedule
document management updates, etc.). Give a short but clear
description. This description is required in the profile.

Profile type-subtype: The type-subtypes of the profile as they will
appear in the text/calendar MIME Content-Type Profile parameter. This
list of type-subtype values is required in the profile.

Profile properties: The list of MIME Calendaring and Scheduling
Content Type properties associated with the profile. This list of
properties that are included in the profile. If a property is
required by the profile, it should noted in this section. Other types
not mentioned in the profile definition may also be present. Note

Dawson/Stenerson 65 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

that any new properties referenced by the profile must be defined
separately as described in section .

Profile special notes: Any special notes about the profile, how it is
to be used, etc. This section is not required in the profile.

4.2

6.2 Post the profile definition

The profile description must be posted to the IETF Calendaring and
Scheduling Working Group discussion list, ietf-calendar@imc.org.

4.3

6.3 Allow a comment period

Discussion on the new profile must be allowed to take place on the
list for a minimum of two weeks. Consensus must be reached on the
profile before submitting the profile for approval.

4.4

6.4 Submit the profile for approval

Once the two-week comment period has elapsed, and the proposer is
convinced consensus has been reached on the profile, the registration
application should be submitted to the Profile Reviewer for approval.

The Profile Reviewer is appointed to the Application Area Directors
and may either accept or reject the profile registration. An accepted
registration should be passed on by the Profile Reviewer to the IANA
for inclusion in the official IANA profile registry. The registration
may 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 Profile
Reviewer's decision to reject a profile may be appealed by the
proposer to the IESG, or the objections raised can be addressed by
the proposer and the profile resubmitted.

4.5

6.5 Profile Change Control

Existing profiles may be changed using the same process by which they
were registered.

1. Define the change

Dawson/Stenerson 60 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

2. Post the change

3. Allow a comment period

4. Submit the profile for approval

Note that the original author or any other interested party may
propose a change to an existing profile, but that such changes should
only be proposed when there are serious omissions or errors in the
published specification. The Profile Reviewer may object to a change
if it is not backwards compatible, but is not required to do so.

Dawson/Stenerson 66 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

Profile definitions can never be deleted from the IANA registry, but
profiles which are no longer believed to be useful can be declared
OBSOLETE by a change to their "intended use" field.

4.6

6.6 Registration of New Content Type Properties

This section defines procedures by which new properties for the MIME
Calendaring and Scheduling Content Type are registered with the IANA.
Note that non-IANA properties may be used by bilateral agreement,
provided the associated properties names follow the "X-" convention
defined above in section 3.1.6.33.

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.

Registration of a new property is accomplished by the following
steps.

4.6.1

6.6.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 data type(s):

Property encoding:

Property special notes (optional):

Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

The meaning of each field in the template is as follows.

Dawson/Stenerson 61 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

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 data type(s): Any of the valid data types for the property
value needs to be specified. The default data type also needs to be
specified. If a new data type is specified, it needs to be declared
in this section.

Dawson/Stenerson 67 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

Property encoding: The encodings permitted for the property value.
This description must be precise and must not violate the general
encoding rules defined in this document.

Property special notes: Any special notes about the property, how it
is to be used, etc.

4.6.2

6.6.2 Post the Property definition

The property description must be posted to the new property
discussion list, ietf-calendar@imc.org.

4.6.3

6.6.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.

4.6.4

6.6.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 Profile Reviewer
for approval. The Profile Reviewer is appointed to the Application
Area Directors and may either accept or reject the property
registration. An accepted registration should be passed on by the
Profile Reviewer to the IANA for inclusion in the official IANA
profile registry. The registration may 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 Profile Reviewer's decision to

reject a property may be appealed by the proposer to the IESG, or the
objections raised can be addressed by the proposer and the property
resubmitted.

4.7 Content Type

6.7 Property Change Control

Existing properties may be changed using the same process by which
they were registered.

Dawson/Stenerson 62 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997

1. Define the change

2. Post the change

3. Allow a comment period

4. Submit the property for approval

Note that the original author or any other interested party may
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 specification. The Profile Reviewer may object to a

Dawson/Stenerson 68 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

change if it is not backwards 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.

7. File extension

The file extension of _vcs_ "vcs" is to be used to designate a file
containing calendaring and scheduling information consistent with
this MIME content type.

8. Macintosh File Type Code

The file type code of _vcal_ "vcal" 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.

7. Bibliography

9. References

The following document are referred to within this document.

[ISO 8601] ISO 8601, Data "Data elements and interchange formats_
Information interchange_Representation of dates and times, times",
International Organization for Standardization, June, 1988. This
standard is also addressed by the Internet Draft document
ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt.

[ISO 9070] ISO/IEC 9070, Information "Information Technology_SGML Support
Facilities_Registration Procedures for Public Text Owner Identifiers,
Identifiers", Second Edition, International Organization for
Standardization, April, 1991.

[MIME-REG] Freed, N., Postel, J., "Multipurpose Internet Mail
Extensions (MIME) - Part Four: Registration Procedures", Internet-
Draft draft-ietf-822ext-mime-reg-02.txt, December 1995.

[MIME DIR] Howes, T., Smith, M., "A MIME Content-Type for Directory
Information", Internet-draft-ietf-asid-mime-direct-05.txt, March,
1997.

[RFC 1738] T. Berners-Lee and L. Masinter , _Universal Resource
Locator_, RFC 1738, Xerox Corporation, University 822] Crocker, D., "Standard for the Format of Minnesota,
December 1994.

Dawson/Stenerson 63 Expires August 1997 ARPA Internet Draft C&S Core Object Specification February 3, 1997 Text
Messages", STD 11, RFC 822, August 1982.

[RFC 1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform
Resource Locators (URL)", RFC 1738, December 1994.

[RFC 1766] H. Alvestrand, _Tags H., "Tags for the Identification of Languages_,
UNINETT, RFC 1766,
Languages", March 1995.

[RFC 1872] Levinson, E., "The MIME Multipart/Related Content-type,"
RFC 1872, December 1995.

[RFC 2045] Freed, N., Borenstein, N., and N. Freed, "Multipurpose " Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
2045, November 1996.

Dawson/Stenerson 69 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

[RFC 2046] Borenstein N., and N. Freed, "Multipurpose N., Borenstein, N., " Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.

[RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.

[RFC 2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) - Part Four: Registration Procedures", RFC
2048, January 1997.

[US-ASCII] Coded "Coded Character Set--7-bit American Standard Code for
Information Interchange, Interchange", ANSI X3.4-1986.

[VCARD] Internet Mail Consortium, "vCard - The Electronic Business
Card Version 2.1", http://www.versit.com/pdi/vcard-21.txt, September
18, 1996.

[VCAL] MIME calendaring entity Internet Mail Consortium, "vCalendar - The Electronic
Calendaring and Scheduling Exchange
Format, Versit Consortium, Format",
http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.

[XAPIA] XAPIA "XAPIA CSA, Calendaring and Scheduling Application
Programming Interface (CSA) Version 1.0, 1.0", X.400 API Association,
November 15, 1994.

10. 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, Denis Bigorgne, John Binici, Bill
Bliss, Andre Courtemanche, Dave Crocker, Alec Dun, Ross Finlayson,
Randell Flink, Ned Freed, Patrik Falstrom, Chuck Grandgent, Mark
Handley, Steve Hanna, Paul B. Hill, Mark Horton, Bruce Kahn, C.
Harald Koch, Theodore Lorek, Keith Moore, Cecil Murray, Chris Newman,
Ralph Patterson, Pete Resnick, Keith Rhodes, Robert Ripberger, Andras
Salamar, Vinod Seraphin, Ken Shan, Andrew Shuman, William P. Spencer,
Mark Towfiq, Robert Visnov, James L. Weiner, Mike Weston, William
Wyatt.

9.
Wyatt, Steve Silverberg.

11. Author's Address

The following address information is provided in a MIME-VCARD,
Electronic Business Card, format.

The authors of this draft are:

BEGIN:VCARD
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;
Raleigh;NC;27613-3502;USA
TEL;WORK;MSG:+1-919-676-9515
TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD

Dawson/Stenerson 64 70 Expires August September 1997

Internet Draft C&S Core Object Specification February 3, March 26, 1997

TEL;WORK;MSG:+1-919-676-9515
TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD

BEGIN:VCARD
FN:Derik Stenerson
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;WORK;MSG:+1-206-936-5522
TEL;WORK;FAX:+1-206-936-7329
EMAIL;INTERNET:deriks@Exchange.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
chairman of that working group is:

BEGIN:VCARD
FN:Anik Ganguly
ORG:OnTime, Inc.
ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern Highway;
Southfield;MI;48075;USA
TEL;WORK;MSG:+1-810-559-5955
TEL;WORK;FAX:+1-810-559-5034
EMAIL;INTERNET:anik@ontime.com
END:VCARD

10.

12. iCalendar Object Examples

The following examples are provided as an informational source of
illustrative MIME entities containing data iCalendar Objects consistent with this MIME content type.

The following is an example of a MIME message with a single body part
consisting of a text/calendar content type. The message specifies a
meeting request between the originator and recipient of the message.

TO:jsmith@host1.com
FROM:jdoe@host1.com
MIME-VERSION:2.0
MESSAGE-ID:<19960704 08:30:00 EDT xyz@host1.com>
CONTENT-TYPE:text/calendar;PROFILE=request,event

BEGIN:VCALENDAR
PROFILE:event-request
VERSION:2.0
BEGIN:VEVENT
DTSTART:19960918T143000Z
DTEND:19960920T220000Z
CATEGORIES:CONFERENCE;PROJECT

Dawson/Stenerson 71 Expires September 1997

Internet Draft C&S Core Object Specification March 26, 1997

SUMMARY:Networld+Interop Conference
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Networld+Interop Conference=
and Exhibit=0D=0A=
Atlanta World Congress Center=0D=0A=
Atlanta, Georgia

Dawson/Stenerson 65 Expires August 1997

Internet Draft C&S Core Object Specification February 3, 1997
END:VEVENT
END:VCALENDAR

The following example message issues a meeting request that does not
require any reply. The message is sent as a singular _text/calendar_ "text/calendar"
content type, body part.

From: jsmith@host1.com
To: ietf-calendar@imc.org
Subject: First IETF-Calendar Working Group Meeting
MIME-Version: 2.0
Message-ID: <id1@host1.com>
Content-Type: text/calendar;Profile=event,request

BEGIN:VCALENDAR
PROFILE:event-request
DAYLIGHT:TRUE;-06:00;19960407T025959;19961027T010000;EST;EDT
PRODID:-//RDU Software//NONSGML HandCal//EN
TZ:-05:00
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org
DESCRIPTION:First IETF-Calendaring and Scheduling Working Group
Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
DCREATED:19961022T083000
CREATED:19961022T083000
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19961210T210000Z
DTEND:19961210T220000Z
LOCATION:San Jose, CA - Fairmont Hotel
UID:guid-1.host1.com
END:VEVENT
END:VCALENDAR

TO:jsmith@host1.com
FROM:jdoe@host1.com
MIME-VERSION:1.0
MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com>
CONTENT-TYPE:text/calendar;PROFILE=event-request

BEGIN:VCALENDAR
PROFILE:event-request
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
SEQUENCE:0

Dawson/Stenerson 66 72 Expires August September 1997

Internet Draft C&S Core Object Specification March 26, 1997

UID:19970324-080045-4000F192713-0052
ATTENDEE;EXPECT=REQUEST:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:CONFERENCE;PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interop Conference
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Calendaring Interop=
Conference and Exhibit=0D=0A=
Atlanta, Georgia
LOCATION:Atlanta World Congress Center
ATTACH;VALUE=URL:file://xyzCorp.com/conf/bkgrnd.ps
END:VEVENT
END:VCALENDAR

Example of a reply to the above request, accepting the meeting.

TO:jdoe@host1.com
FROM:jsmith@host1.com
MIME-VERSION:1.0
MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com>
CONTENT-TYPE:text/calendar;PROFILE=event-reply

BEGIN:VCALENDAR
PROFILE:event-reply
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
SEQUENCE:0
RESPONSE-SEQUENCE:0
UID:19970324-080045-4000F192713-0052
ATTENDEE;STATUS=CONFIRMED;EXPECT=REQUEST:jsmith@host1.com
END:VEVENT
END:VCALENDAR

An example of a meeting cancelation:

TO:jsmith@host1.com
FROM:jdoe@host1.com
MIME-VERSION:1.0
MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com>
CONTENT-TYPE:text/calendar;PROFILE=event-cancel

BEGIN:VCALENDAR
PROFILE:event-cancel
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
UID:19970324-080045-4000F192713-0052
END:VEVENT
END:VCALENDAR

Dawson/Stenerson 73 Expires September 1997

----