Network Working Group                               Frank Dawson, Lotus
Internet Draft                               Derik Stenerson, Microsoft
<draft-ietf-calsch-ical-00.txt>                        February 3, 1997
Expires August 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]. 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.

   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 Calendar Scale ................................................5
  1.1.2 Coordinate Universal Time (UTC) ...............................5
  1.1.3 Daylight Saving Time (DST) ....................................5
  1.1.4 Gregorian Calendar ............................................5
  1.1.5 Local Time ....................................................5
  1.1.6 Standard Time .................................................6
  1.1.7 Time Zone .....................................................6
2. 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 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 Character Set .............................12
    3.1.3.5 Property Value 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


Dawson/Stenerson                   2                Expires August 1997


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


    3.1.3.9 Value Location ...........................................19
    3.1.3.10 Binary Property Values ..................................19
    3.1.3.11 Recurrence Rule Grammar .................................19
  3.1.4 Body Delimiter Properties ....................................20
    3.1.4.1 Calendar Object ..........................................20
    3.1.4.2 Event Component ..........................................20
    3.1.4.3 To-do Component ..........................................21
  3.1.5 Calendar Object Properties ...................................21
    3.1.5.1 Calendar Content Profile .................................21
    3.1.5.2 Calendar Scale ...........................................24
    3.1.5.3 Daylight Savings Rule ....................................24
    3.1.5.4 Geographic Position ......................................25
    3.1.5.5 Product Identifier .......................................25
    3.1.5.6 Time Zone ................................................26
    3.1.5.7 Version ..................................................26
  3.1.6 Event and To-do Component Properties .........................26
    3.1.6.1 Attachment ...............................................26
    3.1.6.2 Attendee .................................................27
    3.1.6.3 Audio Reminder ...........................................32
    3.1.6.4 Categories ...............................................33
    3.1.6.5 Classification ...........................................34
    3.1.6.6 Date/Time Created ........................................35
    3.1.6.7 Date/Time Completed ......................................35
    3.1.6.8 Description ..............................................36
    3.1.6.9 Display Reminder .........................................36
    3.1.6.10 Due Date/Time ...........................................37
    3.1.6.11 Duration ................................................37
    3.1.6.12 End Date/Time ...........................................37
    3.1.6.13 Exception Date/Times ....................................38
    3.1.6.14 Exception Rule ..........................................38
    3.1.6.15 Last Modified ...........................................38
    3.1.6.16 Location ................................................39
    3.1.6.17 Mail Reminder ...........................................39
    3.1.6.18 Number Recurrences ......................................40
    3.1.6.19 Priority ................................................40
    3.1.6.20 Procedure Reminder ......................................40
    3.1.6.21 Related To ..............................................41
    3.1.6.22 Recurrence Date/Times ...................................41
    3.1.6.23 Recurrence Rule .........................................42
    3.1.6.24 Resources ...............................................42
    3.1.6.25 Response Sequence Number ................................43
    3.1.6.26 Sequence Number .........................................44
    3.1.6.27 Start Date/Time .........................................44
    3.1.6.28 Status ..................................................44
    3.1.6.29 Summary .................................................46
    3.1.6.30 Time Transparency .......................................46
    3.1.6.31 Uniform Resource Locator ................................46
    3.1.6.32 Unique Identifier .......................................46
    3.1.6.33 Non-standard Properties .................................47
 3.2 Formal 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. Registration of Content Type Profiles..............................59
 4.1 Define the profile ..............................................59
 4.2 Post the profile definition .....................................60
 4.3 Allow a comment period ..........................................60
 4.4 Submit the profile for approval .................................60
 4.5 Profile Change Control ..........................................60
 4.6 Registration of New Content Type Properties .....................61
  4.6.1 Define the property ..........................................61
  4.6.2 Post the Property definition .................................62
  4.6.3 Allow a comment period .......................................62
  4.6.4 Submit the property for approval .............................62
 4.7 Content Type Property Change Control ............................62
5. File extension.....................................................63
6. Macintosh File Type Code...........................................63
7. Bibliography.......................................................63
8. Acknowledgments....................................................64
9. Author's Address...................................................64
10. Examples..........................................................65

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, 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 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 and to-dos. 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     Definitions

   Date and time terminology is 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 of calendar in general use. For example,
   Gregorian, Buddhist Era, Japanese Emperor Era, Chinese Lunar,
   Islamic, and Jewish Calendars.

1.1.2   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   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   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.

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

1.1.5   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:



Dawson/Stenerson                   5                Expires August 1997


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


        local time = UTC + (offset)

1.1.6   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   Time Zone

   The particular time zone that a location's time 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 is
   observed, the rules will specify the Daylight time offset and either
   a set of rules describing the transition to and from Daylight time or
   absolute dates describing the movement in and out of Daylight time.
   It is important to note that these rules are not static. Time zones
   may 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 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.

2.      TEXT/CALENDAR Registration Information

        [Editor NOTE: This form will be changed to reflect the revision
        to the MIME memos when the respective RFC becomes available.]

     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 1997


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


     Optional parameters: CHARSET

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

     Optional content header fields: CONTENT-LANGUAGE, TRANSFER-ENCODING

     Encoding considerations: This MIME content type does not introduce
     any new encoding considerations beyond those defined in [RFC 2045].

     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 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:

        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: The reference to [RFC 1521] and [MIME-REG] will be
        changed to reflect the revision to the MIME memos when the
        respective RFC becomes available.]

   This memo is meant to serve as the basis for registration of a MIME
   content type per [RFC1521]. It is defined using the MIME content type
   registration from [MIME-REG]. The proposed content type value is
   "TEXT/CALENDAR". This string would label a media type containing


Dawson/Stenerson                   7                Expires August 1997


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


   calendaring and scheduling information encoded primarily as text
   characters formatted 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 as the
   form for 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 this content type.
   Legacy systems that do not understand the _TEXT/CALENDAR_ content
   type will render these MIME entities as they would _TEXT/PLAIN_
   content type. This will provide a minimal level of support for
   calendaring and scheduling information in legacy systems (i.e., the
   ability to display the text tagged calendaring and scheduling content
   information). This 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 be conveyed either as a
   single MIME message entity or as one MIME entity in a multi-part MIME
   message. Additionally, the calendaring and scheduling information may
   be defined in 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 by [RFC 822], [RFC 2045], and [RFC 1766]. A number of
   these message header fields are especially useful to the iCalendar
   Object. These include 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 is used to identify the
   iCalendar Object. The value of this property must be _text/calendar_
   in order to correspond to the media type defined by this document.
   This header field 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 is used to
   identify an alternate character set to the default US-ASCII used by
   the iCalendar Object. This header field parameter is optional for
   MIME entities conforming to this content type.




Dawson/Stenerson                   8                Expires August 1997


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


3.1.1.2 Content-ID Header Field

   The [RFC 2045] Content-ID header field is used by the iCalendar
   Object to provide a persistent, globally unique identifier for a MIME
   Calendar Object within a MIME message entity. This header field is
   required for multi-part MIME entities containing an iCalendar Object
   that conforms to this content type. In the event that the iCalendar
   Object is transported in a MIME message containing a single body,
   then the Message-ID header field is required.

3.1.1.3 Content-Language

   The [RFC 1766] Content-Language header field is used to provide an
   alternate default language for the MIME Calendar Object. The default
   language is _en-US_. This header field is optional for MIME entities
   conforming to this content type.

3.1.1.4 Message-ID Header Field

   The [RFC 2045] Message-ID header field 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 is required for a single body part MIME
   message conforming to this content type. In the event that the
   iCalendar Object is transported as a body part within a multi-part
   MIME message, the Content-ID header field must be specified. The
   Message-ID header field is used to unambiguously refer to the
   iCalendar Object within a MIME entity.

3.1.1.5 Transfer-Encoding Header Field

   The [RFC 2045] Transfer-Encoding header field is used to provide an
   alternate transfer encoding for the iCalendar Object. The default
   transfer encoding is _7BIT_. This header field is required for a MIME
   entity conforming to this content type when any other encoding is
   used in the iCalendar Object.

3.1.2   Additional Content Type Parameter

   In addition to the existing content type parameters defined by [RFC
   2045] and [RFC 1766], this document defines an additional content
   type parameter to be used by the iCalendar Object.

3.1.2.1 Profile

   The MIME Calendar Object defines the Profile content type parameter.
   This parameter is used to specify a usage profile for the iCalendar
   Object. The value of this parameter consists of a type and a subtype
   value pair. The type value is used to specify either a EVENT, TODO,
   or FREE-BUSY type of MIME Calendar Object profile. The subtype value
   is used to specify the scheduling operation being conveyed by the
   profile type. For example, the EVENT and TODO type values might have
   a subtype value of REQUEST, 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 an event or
   to-do delegation message; or the BUSYFREE type value might have a
   subtype value of REQUEST, to convey a free-busy time request message
   , or REPLY, to convey a free-busy time data message. The parameter
   value is defined by the following BNF:

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

     type1 :=   <any IANA values defined by an iCalendar Object usage
     profile or an _X-_ type of non-standard value>

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

   The following is an example of this content type parameter for a
   profile that specifies an event request message, such as in a request
   for a meeting or appointment:

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

   The following is an example of this content type parameter for a
   profile that specifies a to-do delegation message, such as delegating
   a task to another individual:

     CONTENT-TYPE:TEXT/CALENDAR;PROFILE=TODO-DELEGATE

   The following is an example 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 of the body information for this content type.

3.1.3.1 Property

   A property is the definition 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



Dawson/Stenerson                   10               Expires August 1997


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


   A property takes the form of one or more lines of text. The
   specification of property names and property parameters is case
   insensitive. The property name can be one of a set of pre-defined or
   non-standard strings. The property name must appear as the first
   characters on a line. In the previous example, _DTSTART_ is the name
   of the Start Date/Time property. Property values are specified as
   strings. In 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. The parameter value string can be
   specified alone in those cases where the value is unambiguous. For
   example a complete property parameter specification might be:

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

   A valid short version of the same property parameter specification
   might be:

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

3.1.3.2 Delimiters

   Individual lines within the iCalendar Object body are delimited by
   the [RFC 822] line break, which is a CRLF sequence (ASCII decimal 13,
   followed 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 by at least one LWSP-char may
   instead be inserted. For example the line:

     DESCRIPTION:This is 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 process of moving from this folded multiple-line representation
   of a property definition to its single line representation is called
   _unfolding_. Unfolding is accomplished by regarding CRLF immediately
   followed 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 property value, must also be
   specified by a (RFC 822) line break, which is a CRLF sequence.
   However, since the CRLF sequence is used to delimit a line, property
   values with formatted line breaks (i.e., multiple lines) must be
   encoded using an alternate encoding of either Quoted-Printable or
   Base64, as defined in [RFC 2045].


Dawson/Stenerson                   11               Expires August 1997


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


   For example, in the Quoted-Printable encoding the 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 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 are delimited by a field delimiter,
   specified by the Semi-colon character (ASCII decimal 59). A Semi-
   colon character in a property parameter value must be escaped with a
   Backslash character (ASCII decimal 92).

   Compound property values are delimited by a field delimiter,
   specified by the Semi-colon character (ASCII decimal 59). A Semi-
   colon character in a component of a compound property value must be
   escaped with a Backslash character (ASCII decimal 92).

3.1.3.3 Property Value Transfer Encoding

   The default transfer encoding for the iCalendar Object is _7BIT_. The
   default transfer encoding can be overridden for an individual
   property value by using the _ENCODING_ 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 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 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:...



Dawson/Stenerson                   12               Expires August 1997


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


   The MIME CHARSET parameter on the CONTENT-TYPE header field can be
   used to specify a default character set other than ASCII (e.g., UTF-
   8).

3.1.3.5 Property Value Language

   The default language for a iCalendar Object is _en-US_ (US English).
   The default language can be overridden for an individual property
   value by using the _LANGUAGE_ property parameter. The values for this
   property are a string consistent with RFC 1766, Tags for the
   Identification of Languages. This property parameter may be used on
   any property. However, the use of this parameter on some properties,
   such 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 to more fully specify the semantics of this content type and
   to facilitate its automated processing, the specification of each
   property defined by the iCalendar Object identifies the valid data
   types and the default data type for the property value. In addition,
   within an instance of this content type a property may explicitly
   convey the data type information through the DATATYPE property
   parameter. The STRING data type for the DESCRIPTION property would be
   specified by the following:

     DESCRIPTION;DATATYPE=STRING:Weekly Staff Meeting

   If the DATATYPE property parameter is not specified on a property,
   then the default data type for that property is assumed. Usage
   profiles for this content type that introduce new properties must
   specify the default data type for each newly defined property. The
   data types used within this content type definition include the
   following:




              Property Data       Description
                   Type


                  AALARM          Indicates an
                                  audio alarm
                                  value, as
                                  specified 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 a
                                  list of ISO
                                  8601
                                  formatted
                                  date/time
                                  string
                                  values.

                 DURATION         Indicates an
                                  ISO 8601
                                  formatted
                                  duration or
                                  period of
                                  time value.



Dawson/Stenerson                   14               Expires August 1997


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



                  FLOAT           Indicates a
                                  string
                                  representatio
                                  n of a
                                  floating
                                  point value.

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

                 INTEGER          Indicates a
                                  numeric
                                  string
                                  representatio
                                  n of an
                                  integer
                                  value.

               INTEGER-LIST       Indicates a
                                  list of
                                  numeric
                                  string
                                  representatio
                                  ns of an
                                  integer
                                  value.

                  MALARM          Indicates a
                                  mail alarm
                                  value, as
                                  specified by
                                  this
                                  document.

                   MID            Indicates a
                                  string
                                  identifier
                                  value for an
                                  external
                                  message.

                  PALARM          Indicates a
                                  procedure
                                  alarm value,
                                  as specified
                                  by this
                                  document.



Dawson/Stenerson                   15               Expires August 1997


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



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

                  RRULE           Indicates a
                                  recurrence
                                  rule grammar
                                  string value
                                  as specified
                                  in this
                                  document.

                  STRING          Indicates a
                                  text string
                                  value in the
                                  current
                                  character
                                  set.

               STRING-LIST        Indicates a
                                  list of text
                                  string values
                                  in the
                                  current
                                  character
                                  set.

               TIME-OFFSET        Indicates an
                                  ISO 8601
                                  formatted
                                  time offset
                                  value

                   URL            Indicates a
                                  RFC 1738
                                  formatted
                                  Uniform
                                  Resource
                                  Locator
                                  string.



   The property values consisting of lists of a particular data type
   (i.e., STRING-LIST) are semi-colon separated string of list items.

3.1.3.7 Date and Time

   The date and time values for all iCalendar Object properties are
   formatted as a string consistent with the ISO 8601 representation for


Dawson/Stenerson                   16               Expires August 1997


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


   combinations of dates and times. Either the basic or extended format
   is allowed. The use of UTC, rather than local time, should be used
   when ever possible in order to avoid time zone ambiguities. Where
   local time is specified, the inclusion of the UTC offset should also
   be included to avoid time zone ambiguities. The format for the
   complete, representation of a date and time value is represented by
   the following ABNF:

     date-time =        (date / time / (date _T_ time))


     date =     year month day
     year =     <four digits representing the century and year>
     month =    [_-_] <digits representing the month in the year>
     day =      [_-_] <digits representing the day of the month>

     time =     hour minute second [fraction](utc-sign / utc-offset)
     hour =     <digits representing a period of time of 60 minutes>
     minute =   [_:_] <digits representing a period of time of 60
                seconds>
     second =   [_:_] <digits representing a basic measurement unit
                of time in the International System of Units as defined
                in ISO 31-1>
     fraction = _,_ <digits representing fraction of a second>
     utc-sign = _Z_
     utc-offset = [_+_ / _-_] hour [_:_] minute
        ;_+_ if offset is after UTC and _-_ if offset is before UTC

   The basic complete representation does not include the _-_ date
   separator nor the _:_ time separator. The extended complete
   representation does include the separators.

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

     19960415T083000-05:00

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

     19960415T133000Z

   The same date 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 of date and time values,
   then the property value is a string made up of a list of date and
   time values, separated by the field separator, a Semi-Colon (ASCII
   decimal 59). For example:


Dawson/Stenerson                   17               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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. A given duration of a
   period of time 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 of months
   followed by the designator _M_, optionally including the number of
   weeks followed by the designator _W_, optionally including the number
   of days followed by the designator _D_. The sequence can also contain
   a time component preceded by the designator _T_, optionally including
   the number of hours followed by the designator _H_, optionally
   including the number of minutes followed by the designator _M_,
   optionally including the number of seconds followed by the designator
   _S_. The following ABNF describes the representation of ISO 8601
   periods of time:

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

     yr-period =        [yr-parm] [mo-parm] / wk-parm
     yr-parm =          _Y_ <digits representing the number of years>
     mo-parm =          _M_ <digits representing the number 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 the number of hours>
     mn-parm =          _M_ <digits representing the number of minutes>
     sc-parm =          _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 a period of 1 hour and thirty minutes; or

     P2Y10M15DT10H30M20S

   represents a period of 2 years, 10 months, 15 days, 10 hours, 30
   minutes, and 20 seconds.




Dawson/Stenerson                   18               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 to organize
   the property value as a separate MIME entity. The property parameter
   _VALUE_ can be specified to override the _INLINE_ location of the
   property value. In the case of the iCalendar Object being transported
   within a MIME email message, the property value can be specified as
   being located in a separate MIME entity with the _CONTENT-ID_ value;
   or _CID_ for shorthand. In this case, the property value is the
   Content-ID for the MIME entity within the multi-part message that
   contains the property value. The value can also be specified as being
   contained within an another, external message using the _MESSAGE-ID_
   value, 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 may be used on any property. However, the use of this
   parameter on some properties may not make sense; for example 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

   The following specifies a value located out in the content of 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), or video graphic images (e.g., VIDEO/MPEG). As
   specified above the binary information can be referenced with a
   Uniform Reference Locator (URL), referenced within an external MIME
   message, referenced within a particular MIME message body part, or
   placed inline. Inline binary information is included as a property
   value after being binary encoded using Base 64 (default) or Quoted-
   Printable transfer encoding.

3.1.3.11        Recurrence Rule Grammar

   Recurring events within the iCalendar Object may be specified as
   either a list of discrete date and time values or as a recurrence
   rule using a grammar. The basic recurrence rule grammar used by this
   specification is defined in a separate section of this specification.
   The grammar defines a recurrence rule that that is based on the prior
   work of the X.400 API Association's Calendaring and Scheduling
   Subcommittee. It is also based on prior work of the IETF Chronos
   Working Group. Refer to section 3.3.



Dawson/Stenerson                   19               Expires August 1997


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


3.1.4   Body Delimiter Properties

   The body information of a iCalendar Object is defined by a series of
   body fields or properties. This section defines the properties that
   can be used in MIME entities conforming to this content type.

3.1.4.1 Calendar Object

   The body of the iCalendar Object is identified within the body of a
   MIME entity by the appearance of the Begin Calendar Object Delimiter:

     BEGIN:VCALENDAR

   The sentinel string must appear as the first characters in the body
   of the MIME entity and as the first characters on a line.

   The body information of the iCalendar Object is terminated by the
   appearance of the End Calendar Object Delimiter as the first
   characters on a line:

     END:VCALENDAR

   The iCalendar Object is a container for calendar components. These
   can include either event or to-do components. The body of a iCalendar
   Object will generally contain a single calendar event or to-do
   component. However, the body may include multiple event or to-do
   components. This is the case for free-busy time reply messages that
   contain multiple free time intervals in individual calendar
   components.

   The Begin and End Calendar Object Delimiter properties are required
   in a MIME entity conforming to this content type. The data type for
   these properties is a STRING.

3.1.4.2 Event Component

   An Event Component is a grouping of calendaring and scheduling
   properties that defines a component that represents a scheduled
   amount of time on a calendar. For example, it may be an activity;
   such as a one-hour, department meeting from 8 AM to 9 AM, tomorrow 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



Dawson/Stenerson                   20               Expires August 1997


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


   The Event Component can not be nested within another Event or To-do
   Component. If Event components need to be related to each other or to
   a To-do Component, they 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. The data type for these properties is a STRING.

3.1.4.3 To-do Component

   A To-do Component 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 of work assigned to an
   individual; such as _turn in travel expense today_.

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

     BEGIN:VTODO

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

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

     END:VTODO

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

   The Begin and End To-do Component Delimiter properties are required
   for a MIME entity containing a to-do component and conforming to this
   content type. The data type for these properties is a STRING.

3.1.5   Calendar Object Properties

   The following properties may appear between the Begin Calendar Object
   Delimiter and either the Begin Event Component Delimiter or the Begin
   To-do Component Delimiter. These properties define body field values
   that apply to the complete calendar object.

3.1.5.1 Calendar Content 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.




Dawson/Stenerson                   21               Expires August 1997


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


   The calendar property value might include the following usage profile
   values:




              Profile Parameter     Description
              Type/Subtype Value


              EVENT-REQUEST         Make a request for an
                                    event


              EVENT-REPLY           Reply to an event
                                    request


              EVENT-COUNTER         Make a counter proposal
                                    to the event request


              EVENT-DECLINECOUNTER  Decline the counter
                                    proposal to the event
                                    request


              EVENT-MODIFY          Modify a subset of the
                                    details 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 of
                                    the current event
                                    request information


              TODO-REQUEST          Assign a to-do




Dawson/Stenerson                   22               Expires August 1997


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




              TODO-REPLY            Reply to a to-do
                                    assignment


              TODO-COUNTER          Make a counter proposal
                                    for the to-do request


              TODO-DECLINECOUNTER   Decline a counter
                                    proposal for the to-do
                                    request


              TODO-MODIFY           Modify a subset of the
                                    details of an existing
                                    to-do assignment


              TODO-REPLACE          Replace the current to-
                                    do request with a
                                    complete set of
                                    information


              TODO-CANCEL           Cancel an existing to-
                                    do


              TODO-DELEGATE         Delegate an existing
                                    to-do


              TODO-RESEND           Request a duplicate of
                                    the current to-do
                                    request information


              FREEBUSY-REQUEST      Free/busy time request


              FREEBUSY-REPLY        Reply to an existing
                                    free/busy time request
                                    with free/busy time
                                    data




   Other values may be defined by other usage profiles of this content
   type.




Dawson/Stenerson                   23               Expires August 1997


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


   This property is optional for MIME entities conforming to this
   content type. In the event that this property is not specified, the
   recipient of a MIME Calendaring and Scheduling Content Type should
   assume the calendar object is for an _event/request_. The data type
   for this property is STRING.

3.1.5.2 Calendar Scale

   This property is identified by the property name CALENDAR. 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 following is an example of this property:

     CALENDAR:GREGORIAN

   The data type for this property is STRING.

3.1.5.3 Daylight Savings Rule

   This property is identified by the property name DAYLIGHT. This
   property defines the effective daylight savings time rule for
   calendar information specified in the iCalendar Object. More than one
   DAYLIGHT properties can be specified for a series 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 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 property value consists of a sequence of components that define a
   rule for the observance 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 the date and time of the transition from standard
   time to daylight savings time, followed by the date and time 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. The effective start date for the
   DST rule allows for the specification of a series of future DST rules
   for a given time zone. The daylight savings time flag is TRUE if
   daylight savings time is observed, otherwise it is FALSE and no other
   components are specified. The daylight savings time offset value is
   specified in a manner consistent with ISO 8601. The property value is
   a signed numeric indicating the number of hours and possibly minutes
   from UTC. The date and time that the daylight savings time begins and
   ends is specified in a manner consistent with ISO 8601 date and time


Dawson/Stenerson                   24               Expires August 1997


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


   format. The standard time and daylight savings time designations
   correspond to the customary character designations.

   The following are examples of this property:

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

     DAYLIGHT:FALSE

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

   This property is optional for MIME entities conforming to this
   content type. 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.
   The data type for this property is DST-RULE.

3.1.5.4 Geographic Position

   This property is identified by the property name GEO. This property
   specifies information related to the global position of the _home_
   system that created the MIME calendar object. The property value
   specifies longitude and latitude. 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 the equator as a positive or negative
   real number, respectively. 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. 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

   This property is identified by the property name PRODID. This
   property specifies the identifier for the product that created the
   MIME calendar object. The vendor of the implementation should assure
   that this is a globally unique identifier; using some technique such
   as an ISO 9070 FPI value. 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. 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

   This property is identified by the property name TZ. This property
   specifies the standard time zone of the _home_ system that created
   the MIME calendar object. The property value is specified in a manner
   consistent with ISO 8601. The property value is a signed numeric
   indicating 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. The following are examples of this property:

     TZ:-0500

     TZ:+05:30

   This property is optional 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. The
   data type for this property is TIME-OFFSET. Optionally, the data type
   for this property may be STRING.

3.1.5.7 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. The value of this property must be 2.0 to correspond
   to this specification..

   This property is identified by the property name VERSION. 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. The data type for this property is FLOAT.

3.1.6   Event and To-do Component Properties

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

3.1.6.1 Attachment

   This property is identified by the property name ATTACH. The property
   defines an attached object to the MIME calendar object. For example,
   a document to be reviewed at a scheduled event or the process steps
   for a to-do. The property value can be a text string, a reference to
   another message body part or a reference to a URL corresponding to a
   document.

   Multiple attachments may be specified by including multiple ATTACH
   properties within the MIME calendaring entity.



Dawson/Stenerson                   26               Expires August 1997


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


   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. 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 Attendee

   This property is identified by the property name ATTENDEE. The
   property defines an attendee to a group event or to-do. The default
   property value is an (RFC 822) address. The property may include
   property parameters TYPE, for the type of attendee, ROLE, for the
   role of the attendee in the event or to-do; STATUS, for the status of
   the attendee's participation in the event or to-do, RSVP, for
   indicating whether the favor of a reply is requested, EXPECT, to
   indicate the expectation of the attendee's participation by the
   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 may reference a vCard object. This provides a
   useful mechanism to allow more than just the address of the attendee
   to be referenced.

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






















Dawson/Stenerson                   27               Expires August 1997


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




              Property            Description
              Value


              INDIVIDUAL          Indicates
                                  attendee is
                                  an
                                  individual.

              GROUP               Indicates
                                  attendee is a
                                  group of
                                  individuals.

              RESOURCE            Indicates
                                  attendee is a
                                  resource.

              UNKNOWN             Indicates
                                  attendee type
                                  is unknown.




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




              Property            Description
              Value


              ATTENDEE            Indicates an
                                  attendee at
                                  the event or
                                  to-do

              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            Indicates a
                                  delegate of
                                  another
                                  attendee.




   The default value for this property parameter 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        Indicates
                                  event or to-
                                  do requires
                                  action by
                                  attendee

              SENT                Indicates
                                  event or to-
                                  do was sent
                                  out to
                                  attendee

              TENTATIVE           Indicates
                                  event is
                                  tentatively
                                  accepted by
                                  attendee

              CONFIRMED           Indicates
                                  attendee has
                                  confirmed
                                  their
                                  attendance at
                                  the event

              DECLINED            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           Indicates to-
                                  do has been
                                  completed by
                                  attendee

              DELEGATED           Indicates
                                  event or to-
                                  do has been
                                  delegated by
                                  the attendee
                                  to another

              CANCELED            Indicates the
                                  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 parameter is NEEDS ACTION.

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




              Property           Description
              Value


              YES                Indicates a
                                 reply 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                Indicates
                                 request is
                                 for your
                                 information.

              REQUIRE            Indicates
                                 presence is
                                 definitely
                                 required.

              REQUEST            Indicates
                                 presence is
                                 being
                                 requested

              IMMEDIATE          Indicates an
                                 immediate
                                 response
                                 needed.




   The default value for this property parameter is FYI.

   The MEMBER property parameter value is an (RFC 822) address that
   represents the group or distribution list.

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

     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 data type for this property may be URL, MID,
   or CID; in which case the value is a location or message that
   contains information that is to be used to specify the attendee.

3.1.6.3 Audio Reminder

   This property is identified by the property name AALARM. The property
   defines an audio reminder for the MIME calendar object. An audio
   reminder is an alarm that is sounded for a calendar component..

   The value for the audio reminder consists of the Run Time, or 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 to being repeated; Repeat Count, or the number of times
   that the reminder is to be repeated; and the Audio Content, or the
   digital sound to be played when the reminder is executed.

   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.


Dawson/Stenerson                   32               Expires August 1997


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



              AIFF               Indicates
                                 the AIFF
                                 format for
                                 audio
                                 content.




   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. 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

   This property is identified by the property name CATEGORIES. This
   property defines the categories for the MIME calendar component. More
   than one category may 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 calendar component.

   A calendar event/to-do 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 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.
   Additionally, due to the _blind_ nature of most exchange processes
   using this specification, these entity classifications can not serve
   as an enforcement statement for a system receiving a MIME calendar
   object . Rather, they provide a method for capturing the intention of
   the calendar owner for the access to the MIME calendar object
   component.

   The following is an example of this property:

     CLASS:PUBLIC

   The property can have the following values:







Dawson/Stenerson                   34               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 is optional for MIME entities conforming to this
   content type. The data type for this property is STRING.

3.1.6.6 Date/Time Created

   This property is identified by the property name DCREATED. This
   property specifies the date and time that the MIME calendar component
   was created within the originating calendar system. This is not
   necessarily the same date and time that the MIME calendar object was
   created. The date and time value is the local or UTC based time
   expressed in the complete representation, basic or extended format as
   specified in ISO 8601. The following is an example of this property:

     DCREATED:19960329T083000-0500

   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

   This property is identified by the property name COMPLETED. This
   property defines the date and time that the to-do was actually
   completed. The date and time value is expressed in the complete
   representation, basic or extended format as specified in ISO 8601.
   The time can either be in local or UTC based time. 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. The data type for this property is DATE-TIME.

3.1.6.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 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_ 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

   This property is identified by the property name DALARM. The 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 is to be executed; Snooze Time, or
   the duration of time after the Run Time that the reminder is to be
   dormant prior to being repeated; Repeat Count, or the number of times
   that the reminder is to be repeated; and the Display String, or the
   text to be displayed when the reminder is executed.

   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. The default data type for this property is DALARM.
   Optionally, the data type may be specified 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

   This property is identified by the property name DUE. This property
   defines the date and time that the to-do is due to be completed. The
   date and time value is expressed in the complete representation,
   basic or extended format as specified in ISO 8601. The time can
   either be in local 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 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
   calendar component that conforms to this content type. 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 property is identified by the property name DURATION. The
   property specifies an interval or duration of time. This property can
   be used with the DTSTART property to specify a relative 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). 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 Date/Time

   This property is identified by the property name DTEND. This property
   defines the date and time that the event component will end. The date
   and time value is expressed in the complete representation, basic or
   extended format as specified in ISO 8601. The time can either be in
   local 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 is relative to the start of the MIME
   calendar component. Events may have an end date/time but no start
   date/time. In that case, the event does not take up any time. 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. 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

   This property is identified by the property name EXDATE. This
   property defines the list of date/time exceptions for a recurring
   MIME calendar component. 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 or UTC based time. The following is an
   example of this property:

     EXDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z

   This property is optional for MIME entities conforming to this
   content type. The data type for this property is D-T-LIST.
   Optionally, the data type may be URL; in which case the value is the
   location where a list of exception dates can be found. This latter
   case is a useful method for conveying dynamic exceptions dates, such
   as holidays, for a recurring event or to-do.

3.1.6.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 property is a pattern
   specification for the recurrence exception. The following are some
   examples of this property:

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

     EXRULE:D1 #10              // Except daily for 10 occurrences

     EXRULE:YM1 6 7 #8          // Except yearly in June and July for 8
                                // occurrences

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

3.1.6.15        Last Modified

   This property is identified by the property name LAST-MODIFIED. The
   property specifies the date and time that the MIME calendar component
   was last revised. The following is an example of this property:

     LAST-MODIFIED:19960817T133000Z

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




Dawson/Stenerson                   38               Expires August 1997


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


3.1.6.16        Location

   This property 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.

   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 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 URL, MID, or CID.

3.1.6.17        Mail Reminder

   This property is identified by the property name MALARM. 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 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 to being repeated; Repeat Count, or the number of times
   that the reminder is to be repeated; Email Address, or the (RFC 822)
   email address that is to be sent the reminder, Subject, or the
   textual subject of the note, and the Note, or the textual reminder
   string that is to be sent to the email address.

   The following is an example of this property:

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

   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. The default data type for this property is MALARM.
   Optionally, the data type may be URL, MID, or CID.






Dawson/Stenerson                   39               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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
   value is equal to the number of recurrences that are specified by the
   union of the Recurrence Dates, Recurrence Rule, Exception Dates, and
   Exception Rule property values. The following is an example 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. The data type for this property is INTEGER.

3.1.6.19        Priority

   This property is identified by the property name PRIORITY. The
   property defines the priority for the MIME calendar component. The
   value is an alphanumeric. 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 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

   This property is identified by the property name PALARM. The property
   defines a procedure reminder for the MIME calendar component. A
   procedure reminder is a procedure, or application executable that
   will be run as an alarm for a calendar component.

   While this property has many useful purposes, implementers should be
   aware of 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.

   The value for the procedure reminder consists of the Run Time, or 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 to being repeated; Repeat Count, or the number of times
   that the reminder is to be repeated; and the Procedure Name, or the
   path to the procedure to be run when the reminder is executed.
   Parameters are passed to the procedure by concatenating to the


Dawson/Stenerson                   40               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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

   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. 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 this relationship.

   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 data type may be URL, MID, or CID.

3.1.6.22        Recurrence Date/Times

   This property is identified by the property name RDATE. This property
   defines the list of date/times for a recurring MIME 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 or UTC based time. The number of recurring date/times is
   specified by the Number Recurrences property. The following is an
   example of this property:

     RDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z

   This property is optional for MIME entities conforming to this
   content type. The default data type for this property is D-T-LIST.
   Optionally, the data type may be URL; in which case the value is the
   location where a list of recurring dates can 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        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]. The
   value for the property is a pattern specification for the recurrence.
   This property may appear along with the RDATE property to define an
   aggregate set of repeating occurrences. When they both appear in an
   iCalendar Object, the recurring events are defined by the union of
   occurrences defined by both the RDATE and RRULE. The following are
   examples of this property:

     RRULE:W2 TU TH                     // Every other week, on Tuesday
                                        // and Thursday

     RRULE:D1 #10                       // Daily for 10 occurrences

     RRULE:YM1 6 7 #8                   // Yearly in June and July for 8
                                        // occurrences

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

3.1.6.24        Resources

   This property is identified by the property name RESOURCES. This
   property defines the equipment or resources needed in the MIME
   calendar component.

   Some of the values that the property may have include 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

              TV

              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 the property name RESPONSE-SEQUENCE.
   This property defines the instance of the MIME calendar component in
   a revision sequence of responses. This property is needed to properly
   handle the receipt and processing of a sequence of MIME calendar
   components that have been delivered out of order. Such is the case
   for store-and-forward based transports. When a response to an
   original MIME calendaring entity is created its sequence number is
   zero (ASCII decimal 48). It is incremented each time it is revised.
   The following is an example of this property:

     RESPONSE-SEQUENCE:1

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


Dawson/Stenerson                   43               Expires August 1997


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


3.1.6.26        Sequence Number

   This property is identified by the property name SEQUENCE. This
   property defines the instance of the MIME calendar component in a
   sequence of revisions. This property is needed to properly handle the
   receipt and processing of a sequence of MIME calendar components that
   have been delivered out of order. Such is the case for store-and-
   forward based transports. When a MIME calendaring entity is created
   its sequence number is zero (ASCII decimal 48). It is incremented
   each time it is revised by the OWNER and/or ORGANIZER. The following
   is an example of this property:

     SEQUENCE:1

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

3.1.6.27        Start Date/Time

   This property is identified by the property name DTSTART. This
   property defines the date and time that the calendar component will
   start. The date and time value is expressed in the complete
   representation, basic format as specified in ISO 8601. The time can
   either be in local 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 start is relative to another MIME
   calendar component specified by the RELATED-TO property. Events may
   have a start date/time but no end date/time. In that case, the event
   does not take up any time. The following is an example of this
   property:

     DTSTART:19960401T235959-0600

   This property is optional for MIME entities conforming to this
   content type. The default data type for this property is DATE-TIME.
   Optionally, the data type may be DURATION.

3.1.6.28        Status

   This property is identified by the property name STATUS. This
   property defines the status associated with the MIME calendar
   component. This property can only be used when the ATTENDEE property
   is either not supported or not needed. The following is an example of
   this property:

     STATUS:TENTATIVE

   The property can have the following values:




              Description           Property



Dawson/Stenerson                   44               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 for MIME entities containing a to-do
   calendar component conforming to this content type. This property is
   optional for MIME entities containing an event calendar component
   conforming to this content type. The data type for this property is
   STRING.


Dawson/Stenerson                   45               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 of this property:

     SUMMARY:Department Party

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

3.1.6.30        Time Transparency

   This property is identified by the property name TRANSP. This
   property defines whether 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 the entry will blocks time and
   will be factored into a free time search. A value 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 the numeric value
   to provide a layering of levels of transparency. The default value is
   zero (ASCII decimal 48), the event is not transparent and will block
   free time searches. The following is an example of this property:

     TRANSP:0

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

3.1.6.31        Uniform Resource Locator

   This property is identified by the property name URL. This property
   defines a Uniform Resource Locator for an Internet location that can
   be used to obtain real-time information associated with the MIME
   calendar component. Valid values for this property are a string
   conforming to [RFC 1738]. The following is an example of this
   property:

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

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

3.1.6.32        Unique Identifier

   This property is identified by the property name UID. This property
   defines a persistent, globally unique identifier associated with the
   MIME 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 a
   statistically high likelihood 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
   the URL reference a service which can provide an updated version of
   the MIME calendar component. 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. The default data type for this property is STRING.
   Optionally, the data type may be URL, MID, 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_. This extension support is
   provided for implementers to _push the envelope_ on the existing
   version of the specification. Extension properties are specified by
   property and/or property parameter names that have the initial sub-
   string of X- (the two character sequence: Capital X character
   followed by the Dash character). It is recommended that vendors
   concatenate onto this sentinel an added short sub-string to identify
   the vendor. This will facilitate readability of the extensions and
   minimize possible collision of names between different vendors. User
   agents that support this content type are expected to be able to
   parse the extension properties and property parameters but may ignore
   them. The following might be 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
   is STRING. Optionally, the data type may be any of the other valid
   data types.

3.2     Formal Definition

   The following modified Backus-Naur Notation (BNF) is provided to
   assist developers in building parsers for the properties of this MIME
   content type..

     This syntax 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.)


Dawson/Stenerson                   47               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 with line separators

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

        ; The value must be in the encoding type specified for 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>

        ; the end of the text is marked with two CRLF sequences

        ; this results in one blank line before the start of the next

        ; 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    = _PROFILE_

                  [parms] _:_ value CRLF

                / _DAYLIGHT_

                  [params] _:_ value CRLF

                / _CALENDAR_

                  [params] _:_ _GREGORIAN_ CRLF

                / _GEO_

                  [params] _:_ value CRLF

                / _PRODID_

                  [params] _:_ value CRLF

                / _TZ_

                  [params] _:_ value CRLF

                / _VERSION_ _:_ _1.0_ CRLF

        ; The VERSION calendar property MUST appear in the MIME Calendar
        ; Object.

     entprops   = entprops *CRLF entprop

                / entprop

     entprop    = [ws] simprop

                  [params] _:_ value CRLF

                / [ws] _AALARM_


Dawson/Stenerson                   49               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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        = 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    = _APPOINTMENT_ / _BUSINESS_ / _EDUCATION_ / _HOLIDAY_

                / _MEETING_ / _MISCELLANEOUS_ / _NOT-IN-OFFICE_

                / _NON-WORKING-HOURS_ / _PERSONAL_ / _PHONE CALL_

                / _SICK DAY_ / _SPECIAL OCCASION_ / _TRAVEL_

                / _VACATION_ / _X-_ word / value

     classvals  = _PUBLIC_ / _PRIVATE_ / _CONFIDENTIAL_ / _X-_ word

                 / 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 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 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 defined in RFC 1766>

     roleval    = _ATTENDEE_ / _ORGANIZER_ / _OWNER_ / _X-_ word

     statusval  = _ACCEPTED_ / _            _ /
                                NEEDS ACTION    _SENT_ / _TENTATIVE_

                / _CONFIRMED_ / _DECLINED_ / _COMPLETED_ / _DELEGATED_

                / _X-_ word

     strnosemi  = *(*nonsemi (_\;_ / _\_ CRLF)) *nonsemi



Dawson/Stenerson                   52               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 by the use of
   a grammar or rule notation. This specification makes use of the Base
   Recurrence Rule Grammar from the [XAPIA].

   A recurrence rule is a string or clear-text encoding of a recurrence
   specification. A recurrence rule is composed of several components. A
   rule begins with a frequency which describes the type 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 and either an end date or a duration.

   Below is the form of a typical rule. This example causes events to be
   generated every other week on Tuesday and Thursday, for 8
   occurrences:

     W2 TU TH #4

   Where, W is the Frequency, 2 is the Interval, TU and TH are the
   optional Frequency Modifiers, and #4 is the Duration.

   The basic recurrence rule grammar supports six types of repetition.
   The six types follow the same form with only the frequency name and
   optional modifier information changing from one type of frequency to
   the next.

3.3.1   Daily Rule

   The daily rule is used for specifying repeating events based on an
   interval of a day or more. These can range from every day to every
   200th day and beyond. 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 for 10 occurrences:
        D1 #10

     Daily until 12/24/94:
        D1 19941224T000000Z

     Every other day - forever:
        D2 #0




Dawson/Stenerson                   53               Expires August 1997


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


     Every 10 days, 5 occurrences:
        D10 #5

3.3.2   Weekly Rule

   The weekly rule is used for specifying repeating events based on an
   interval of a week or more. The basic weekly rule has the same form
   as the daily rule except that the rule begins with a W and can
   contain an optional list of weekdays the events are generated on. For
   weekly rules, 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 and Friday until 12/24/94:
        W2 MO WE FR 19941224T000000Z

3.3.3   Monthly Rule

   The monthly rule is used for specifying repeating events base on an
   interval of a month or more. There are two types of monthly
   recurrence rules. One for by-position and one for by-day. The by-
   position rule allows weekdays 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 may be used in monthly by-position
   rules. The occurrence specifiers control which occurrence of a
   weekday in a month an event occurs on:

     1+, 2+, ... 5+ for the first occurrence, second, ...fifth
     occurrence of the month.

     1-, 2-, ... 5- for the last occurrence, second to last occurrence,
     etc.

   A 2+ FR SA would indicate the second occurrence of Friday and
   Saturday in the month. A 1- MO would indicate the first occurrence of
   Monday working from the end of the month backwards (i.e., the last
   occurrence). A 2- MO would be the second to the last Monday of the
   month.

   A by-day rule allows actual day numbers to be specified such as the
   12th day or 29th day.



Dawson/Stenerson                   54               Expires August 1997


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


   The by-position rule begins with a MP and the by-day rule begins with
   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 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 on the second to the last day for 5 months. So, if the
     start 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 for specifying repeating events based on an
   interval of a year or more. There are two types of yearly recurrence
   rules. One for by-month and one for by-day. The by-month rule allows
   specific months out of the year to be specified. The by-day allows
   specific days to be specified. In the by-month rule, the day in the
   month the rule is to occur on is determined from the initial
   appointment.




Dawson/Stenerson                   55               Expires August 1997


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


   The by-month rule begins with a YM and 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 other year on January, Feb, and March for 10 occurrences:
        YM2 1 2 3 #10

     Every 3rd year on the 1st, 100th 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 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>}



Dawson/Stenerson                   56               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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                A number representing a month of the year.

   day          A number representing a day of the year.

   occurrence   Controls which week of the month a particular weekday
   event occurs.


Dawson/Stenerson                   57               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 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 a rule defines the total number of events
     the rule generates, including the first event.

   2.
     Information, not contained in the rule, necessary to determine the
     next event time and date is derived from the Start Time entry
     attribute.

   3.
     If an end date and a duration is specified in the rule, the
     recurring event ceases when the end date is reached or the number
     of events indicated in the duration occur; whichever comes first.

   4.
     If the duration or an end date is not established in the rule
     (e.g., D4) the event occurs twice. That is D4 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 the
     duration. The same applies to providing a day of the month that
     does not occur in the month. For example the 30th or 31st .

   7.
     The start time and date of an entry 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 or W1 #5


Dawson/Stenerson                   58               Expires August 1997


Internet Draft       C&S Core Object Specification     February 3, 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 date and the <weekday> used is the day of the week the entry
     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
     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 is the third Wednesday of the month) repeats on 8/17/94
     which is the third Wednesday of the month.

4.      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     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
   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     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     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     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     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.

   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     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   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.

   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   Post the Property definition

   The property description must be posted to the new property
   discussion list, ietf-calendar@imc.org.

4.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   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 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
   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.

5.      File extension

   The file extension of _vcs_ is to be used to designate a file
   containing calendaring and scheduling information consistent with
   this MIME content type.

6.      Macintosh File Type Code

   The file type code of _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

   The following document are referred to within this document.

   [ISO 8601] ISO 8601, Data elements and interchange formats_
   Information interchange_Representation of dates and 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 Technology_SGML Support
   Facilities_Registration Procedures for Public Text Owner 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.

   [RFC 1738] T. Berners-Lee and L. Masinter , _Universal Resource
   Locator_, RFC 1738, Xerox Corporation, University of Minnesota,
   December 1994.


Dawson/Stenerson                   63               Expires August 1997


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


   [RFC 1766] H. Alvestrand, _Tags for the Identification of Languages_,
   UNINETT, RFC 1766, March 1995.

   [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
   Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
   2045, November 1996.

   [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail
   Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

   [US-ASCII] Coded Character Set--7-bit American Standard Code for
   Information Interchange, ANSI X3.4-1986.

   [VCAL] MIME calendaring entity - Calendaring and Scheduling Exchange
   Format, Versit Consortium, September 18, 1996.

   [XAPIA] XAPIA CSA, Calendaring and Scheduling Application Programming
   Interface (CSA) Version 1.0, X.400 API Association, November 15,
   1994.

8.      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.      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               Expires August 1997


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




     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.     Examples

   The following examples are provided as an informational source of
   illustrative MIME entities containing data 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
     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_
   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
     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






















Dawson/Stenerson                   66               Expires August 1997