view Side-By-Side changes

Network Working Group                               Frank Dawson, Lotus
Internet Draft                               Derik Stenerson, Microsoft
<ietf-calsch-ical-02.txt>                                 July 29,
<draft-ietf-calsch-ical-03.txt>                        October 22, 1997
Expires January Mary 1998


     Internet Calendaring and Scheduling Core Object Specification
                              (iCalendar)


Status of this Memo


   This document memo 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 MAY also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months. Internet-Drafts may 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 memo is unlimited.

   Copyright (C) The Internet Society 1997. All Rights Reserved.


Abstract


   There is a clear need to provide and deploy interoperable calendaring
   and scheduling services for the Internet. Current group scheduling
   and Personal Information Management (PIM) products are being extended
   for use across the Internet, today, in proprietary ways. This
   document memo
   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
   [RFC 2048]. However, the format in this memo is equally applicable
   for use outside of a MIME message content type.

   The proposed media type value is 'TEXT/CALENDAR'. ''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
   or using HTTP. In addition, the content type is useful as an object



Dawson/Stenerson                   1                    Expirs MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   for interactions between desktop applications using the operating
   system clipboard, drag/drop or file systems capabilities.



Dawson/Stenerson                   1                ExpiresJanuary 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   This document memo is based on the earlier work of the vCalendar specification
   for the exchange of personal calendaring and scheduling information.
   In order to avoid confusion with this referenced work, this document memo is
   to be known as the iCalendar specification. This
   document memo is based on the
   calendaring and scheduling model defined in
   [ICMS]. []. The document is also
   the basis for the calendaring and scheduling interoperability
   protocol defined in [ITIP-1], [ITIP-2]
   and [ITIP-3]. [ITIP].

   This document memo also includes the format for defining content type
   profiles. A content type profile iCalendar object
   methods. An iCalendar object method 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 these methods might define
   scheduling messages that request an event be scheduled, reply to an
   event request, send a cancellation notice for an event, modify or
   replace the definition of an event, provide a counter proposal for an
   original event request, delegate an event request to another
   individual, request free or busy time, reply to a free or busy time
   request, or provide similar scheduling messages for a to-do or
   journal entry calendar component.



































Dawson/Stenerson                   2                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997



   Table of Contents

1. Introduction........................................................5

1......................................................................7
Introduction...........................................................8
2. Basic Grammar and Conventions.......................................5 Conventions.......................................8
 2.1 Formatting Conventions...........................................9
 2.2 Related Memos...................................................10
3. Definitions.........................................................6
 3.1 Alarm............................................................6
 3.2 Busy Time........................................................6
 3.3 Calendar Component...............................................6
 3.4 Calendar Date....................................................6
 3.5 Calendar Object..................................................7
 3.6 Calendar Properties..............................................7
 3.7 Calendar Scale...................................................7
 3.8 Component Properties.............................................7
 3.9 Coordinate Universal Time (UTC)..................................7
 3.10 Daylight Saving Time (DST)......................................7
 3.11 Event...........................................................7
 3.12 Free Time.......................................................7
 3.13 Gregorian Calendar..............................................8
 3.14 Journal.........................................................8
 3.15 Local Time......................................................8
 3.16 Period..........................................................8
 3.17 Recurrence Rule.................................................8
 3.18 Reminder........................................................8
 3.19 Repeating Event or To-do........................................8
 3.20 Standard Time...................................................8
 3.21 Time Zone.......................................................9
 3.22 To-do...........................................................9
4. TEXT/CALENDAR Registration Information..............................9
5. Information.............................10
4. iCalendar Object Specification.....................................11
 5.1 Syntax Considerations...........................................11
  5.1.1 Specification.....................................12
 4.1 Content Considerations..........................................13
  4.1.1 Content Lines................................................13
  5.1.2
  4.1.2 List and Field Separators....................................14
  5.1.3
  4.1.3 Multiple Values..............................................14
  5.1.4 Character Set................................................15
  5.1.5 Language.....................................................15
  5.1.6 Content Encoding.............................................15
  5.1.7 Values..............................................15
  4.1.4 Binary Content...............................................15
  5.1.8 Recurrence Set...............................................15
  5.1.9
  4.1.5 Property Parameters..........................................15
  4.1.6 Alternate Text Representation................................16
  4.1.7 Character Set................................................17
  4.1.8 Language.....................................................17
  4.1.9 Value Data Types...................................................16
 5.2 Types.............................................17
 4.2 iCalendar Object................................................21
 5.3 Property........................................................21
 5.4 object................................................28
 4.3 Property........................................................28
 4.4 Calendar Components.............................................22
  5.4.1 Components.............................................29
  4.4.1 Event Component..............................................22
  5.4.2 Component..............................................29
  4.4.2 To-do Component..............................................23
  5.4.3 Component..............................................31
  4.4.3 Journal Component............................................23
  5.4.4 Component............................................31
  4.4.4 Free/Busy Component..........................................24
  5.4.5 Component..........................................32
  4.4.5 Alarm Component..............................................25
  5.4.6 Component..............................................33
  4.4.6 Timezone Component...........................................26
 5.5 Component...........................................34
 4.5 Calendar Properties.............................................30
  5.5.1 Properties.............................................38
  4.5.1 Calendar Scale...............................................30
  5.5.2 Scale...............................................38
  4.5.2 Method.......................................................39
  4.5.3 Product Identifier...........................................30
  5.5.3 Profile......................................................31
  5.5.4 Profile Version..............................................31
  5.5.5 Source.......................................................32
  5.5.6 Identifier...........................................39
  4.5.4 Source.......................................................40
  4.5.5 Source Name..................................................32
  5.5.7 Version......................................................32 Name..................................................40
  4.5.6 Version......................................................41
 4.6 Component Properties............................................41
  4.6.1 Attachment...................................................41
  4.6.2 Attendee.....................................................42
  4.6.3 Categories...................................................44
  4.6.4 Classification...............................................45
  4.6.5 Comment......................................................46
  4.6.6 Contact......................................................46
  4.6.7 Date/Time Completed..........................................47
  4.6.8 Date/Time Created............................................47
  4.6.9 Date/Time Due................................................47
  4.6.10 Date/Time End...............................................48
  4.6.11 Date/Time Stamp.............................................48
  4.6.12 Date/Time Start.............................................49
  4.6.13 Daylight....................................................49
  4.6.14 Description.................................................50
  4.6.15 Duration....................................................50
  4.6.16 Exception Date/Times........................................51
  4.6.17 Exception Rule..............................................52


Dawson/Stenerson                   3                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

 5.6 Component Properties............................................33
  5.6.1 Attachment...................................................33
  5.6.2 Attendee.....................................................33
  5.6.3 Categories...................................................36
  5.6.4 Classification...............................................36
  5.6.5 Comment......................................................37
  5.6.6 Date/Time Completed..........................................37
  5.6.7 Date/Time Created............................................38
  5.6.8 Date/Time Due................................................38
  5.6.9 Date/Time End................................................38
  5.6.10 Date/Time Stamp.............................................39
  5.6.11 Date/Time Start.............................................39
  5.6.12 Daylight....................................................40
  5.6.13 Description.................................................40
  5.6.14 Duration....................................................41
  5.6.15 Exception Date/Times........................................41
  5.6.16 Exception Rule..............................................42
  5.6.17


  4.6.18 Free/Busy Time..............................................42
  5.6.18 Time..............................................52
  4.6.19 Geographic Position.........................................43
  5.6.19 Position.........................................54
  4.6.20 Last Modified...............................................44
  5.6.20 Location....................................................44
  5.6.21 Priority....................................................45
  5.6.22 Modified...............................................54
  4.6.21 Location....................................................54
  4.6.22 Percent Complete............................................55
  4.6.23 Priority....................................................56
  4.6.24 Recurrence Date/Times.......................................45
  5.6.23 Date/Times.......................................56
  4.6.25 Recurrence ID...............................................46
  5.6.24 ID...............................................57
  4.6.26 Recurrence Rule.............................................46
  5.6.25 Rule.............................................58
  4.6.27 Related To..................................................52
  5.6.26 To..................................................65
  4.6.28 Repeat Count................................................53
  5.6.27 Count................................................66
  4.6.29 Request Status..............................................53
  5.6.28 Resources...................................................55
  5.6.29 Response Status..............................................66
  4.6.30 Resources...................................................68
  4.6.31 Sequence Number....................................56
  5.6.30 Sequence Number.............................................56
  5.6.31 Status......................................................57
  5.6.32 Summary.....................................................57
  5.6.33 Number.............................................68
  4.6.32 Status......................................................69
  4.6.33 Summary.....................................................70
  4.6.34 Time Transparency...........................................58
  5.6.34 Transparency...........................................70
  4.6.35 Time Zone Name..............................................58
  5.6.35 Name..............................................71
  4.6.36 Time Zone Offset............................................59
  5.6.36 Offset............................................71
  4.6.37 Uniform Resource Locator....................................59
  5.6.37 Locator....................................71
  4.6.38 Unique Identifier...........................................59
  5.6.38 Identifier...........................................72
  4.6.39 Non-standard Properties.....................................60
6. Properties.....................................73
5. Recommended Practices..............................................60
7. Practices..............................................73
6. Registration of Content Type Elements..............................61
 7.1 Elements..............................74
 6.1 Registration of New and ModifiedProfiles........................61
 7.2 Modified iCalendar object Methods.......74
 6.2 Registration of New Properties..................................61
  7.2.1 Properties..................................74
  6.2.1 Define the property..........................................61
  7.2.2 property..........................................74
  6.2.2 Post the Property definition.................................62
  7.2.3 definition.................................75
  6.2.3 Allow a comment period.......................................62
  7.2.4 period.......................................75
  6.2.4 Submit the property for approval.............................62
 7.3 approval.............................75
 6.3 Property Change Control.........................................63
8. Control.........................................76
7. File extension.....................................................63
9. extension.....................................................76
8. Macintosh File Type Code...........................................63 Code...........................................76
9. References.........................................................76
10. References........................................................63 Acknowledgments...................................................78
11. Acknowledgments...................................................65 Copyright.........................................................78
12. Author's Address..................................................65 Address..................................................78
13. iCalendar Object Examples.........................................66 object Examples.........................................79
14. Full Copyright Statement..........................................82



1.













Dawson/Stenerson                   4                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997



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

   The calendaring and scheduling model implemented by this
   specification memo is
   defined in the [ICMS].

   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 definition of a calendaring and scheduling interoperability
   protocol is the subject of another specification [ITIP-1], [ITIP-2]
   and [ITIP-3]. memo [ITIP].

   The specification memo also provides for the definition of usage profiles iCalendar object methods
   that will map this content type to a set of messages for supporting
   calendaring and scheduling operations such as requesting, replying
   to, modifying, and canceling meetings or appointments, to-dos and
   journal entries. The usage profiles iCalendar object methods can be used to define
   other calendaring and scheduling operations such a requesting for and
   replying with free/busy time data.

   The specification memo 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. memo.

2.      Basic Grammar and Conventions


   This


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interopreted as described in [RFC 2119].

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



Dawson/Stenerson                   5                   Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The notation used in this document memo is the augmented BNF notation of [RFC
   822]. Readers intending on implementing this format defined in

Dawson/Stenerson                   5               Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997 this document
   memo should be familiar with this notation in order to properly
   interpret the specifications of this document. memo.

   All numeric and hexadecimal values used in this document memo are given in
   decimal notation. All names of properties, property parameters,
   enumerated property values and property parameter values are case-
   insensitive. However, all other property values are case-sensitive,
   unless otherwise stated.

        Note: All indented editorial notes, such as this one, are
        intended to provide the reader with additional information that
        is not essential to the building of a conformant implementation
        of the specifications of this document. memo. The information is provided
        to highlight a particular feature or characteristic of the
        specifications.

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

3.      Definitions


   EDITORS' NOTE: This section may be removed if

2.1     Formatting Conventions


   The mechanisms defined in this text is added memo are defined in propose. In order
   to refer to elements of the [ICSM].

   Date and time, as well as, calendaring and scheduling terminology are
   used in every day conversations. However, there model, core
   object or interoperability protocol defined in this memo, [ICMS] and
   [ITIP], some formatting conventions have been used. Calendaring and
   scheduling roles defined by [ICMS] are precise
   definitions of many referred to in quoted-strings
   of these terms that are used by this memo.

3.1     Alarm


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

3.2     Busy Time


   A period text with the first character of time on each word in upper case. For
   example, "Organizer" refers to a calendar where there is already scheduled one
   or more events or that is otherwise not available for scheduling.

3.3     Calendar Component


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

3.4     Calendar Date


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




Dawson/Stenerson                   6               Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

3.5     Calendar Object


   An entity consisting of an organized collection
   this memo are referred to with capitalized, quoted-strings of text.
   All calendar
   properties and calendar components. The calendar object is identified
   by unique delimiters.

3.6     Calendar Properties


   Attributes that apply to components start with the calendar object as a whole. letter "V". For example,
   the iCalendar version used
   "VEVENT" refers to format the calendar object, an
   identifier of the product that created the event calendar object, component, "VTODO" refers to
   the to-do calendar scale used component and "VJOURNAL" refers to represent the daily
   journal calendar information and time
   zone information.

3.7     Calendar Scale


   The particular type component. Scheduling methods defined by [ITIP] are
   referred to with capitalized, quoted-strings of calendar in general use. For example,
   Gregorian, Buddhist Era, Japanese Emperor Era, Chinese Lunar,
   Islamic, and Jewish Calendars.

3.8     Component Properties


   Attributes that can only appear within one or more calendar
   components. text. For example,
   "REQUEST" refers to the due date can only appear within method for requesting a to-do scheduling calendar component. The start date and time applies
   component be created or modified, "REPLY" refers to both the event
   and method a
   recipient of a request uses to update their status with the to-do
   "Organizer" of the calendar component.

3.9     Coordinate Universal Time (UTC)

   The time scale maintained properties defined by this memo are referred to with capitalized,
   quoted-strings of text, followed by the Bureau International de l’Heure
   (International Time Bureau) that forms word "property". For example,
   "ATTENDEE" property refers to the basis iCalendar property used to convey
   the calendar address of a coordinated
   dissemination of standard frequencies and time signals. UTC is often
   incorrectly calendar user. Property parameters defined
   by this memo are referred to as GMT.

3.10    Daylight Saving Time (DST)


   An adjustment to local to accommodate annual changes in the number with lower case, quoted-strings of
   daylight hours. DST is also known as Advanced Time, Summer Time, or
   Legal Time. Daylight saving time adjustments in text,
   followed by the southern
   hemisphere are opposite word "parameter". For example, "value" parameter
   refers to those in the northern hemisphere.

3.11    Event


   A calendar component that defines iCalendar property parameter used to override the
   default data type for a scheduled activity, minimally
   specified property value. Enumerated values defined by a start and end calendar date and time of day and a
   description.

3.12    Free Time


   A period of time available on a calendar.




Dawson/Stenerson                   7                   6                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

3.13    Gregorian Calendar


   A calendar scale in general use beginning in 1582. It was introduced


   this memo are referred to correct an error in with capitalized text, either alone or
   followed by the Julian Calendar scale. The Gregorian
   Calendar scale is based on word "value".

2.2     Related Memos


   Implementers will need to be familiar with several other memos that,
   along with this memo, form a solar calendar consisting of common
   years made up of 365 days framework for Internet calendaring and leap years made up of 366 days; both
   divided into 12 sequential months.

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

3.14    Journal


   A calendar component that defines
   scheduling standards. This memo, [ICAL], specifies a collection core
   specification of information
   intended for human presentation objects, data types, properties and is minimally specified by property
   parameters.

   [ICMS] - specifies a
   calendar date common terminology and one or more descriptions.

3.15    Local Time


   The clock time in public use in a locale. Local abstract;

   [ITIP] - specifies an interoperability protocol for scheduling
   between different implementations;

   [IMIP] specifies an Internet email binding for [ITIP];

   [IRIP] - specifies an Internet real time is often
   referenced by protocol binding for [ITIP].

   This memo does not attempt to repeat the customary name specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the time zone in which it is
   located. specification of these
   concepts or definitions.

3.      TEXT/CALENDAR Registration Information


   The relationship between local time Calendaring and UTC is based on the
   offset that Scheduling Core Object Specification is in use intended
   for use as a particular time zone. In general, MIME content type. However, the
   formula is as follows:

        local time = UTC + (offset)

3.16    Period


   A duration implementation of time, specified the
   memo is in no way limited solely as either a defined length of time or
   by its beginning and end points.

3.17    Recurrence Rule


   A notation used MIME content type.

   The following text is intended to represent repeating occurrences, or register this memo as the exceptions
   to such a repetition MIME
   content type "text/calendar".

     To: ietf-types@uninett.no

     Subject: Registration of an event or a to-do. MIME content type text/calendar.

     MIME media type name: text

     MIME subtype name: calendar

     Required parameters: method

     The recurrence rule can
   also be "method" parameter is used in to convey the specification of a time zone description. This
   document defines a particular notation used in recurrence rules
   within this specification.

3.18    Reminder


   See Alarm.

3.19    Repeating Event or To-do


   An event or to-do that repeats iCalendar object
     method to which the calendaring and scheduling information
     pertains. It also is an identifier for one or more additional
   occurrences. the set of properties that
     the iCalendar object will consist of. The recurrence may be defined with discrete dates and
   times and/or with a recurrence rule.

3.20    Standard Time


   Introduced by Sir Sanford Fleming and others around 1870, standard
   time parameter is to be used
     as a scheme guide for dividing applications interpreting the world into zones where information contained
     within the same
   time would body part. It should NOT be kept. The original proposal was used to divide exclude or require
     particular pieces of information unless the world identified method
     definition specifically calls for this behavior. Unless
     specifically forbidden by a particular method definition, a



Dawson/Stenerson                   8                   7                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

   into 24 zones, each zone having a width of 15 degrees


     text/calendar content type MAY contain any set 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 properties
     permitted 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 Calendaring and regions specify 30 or 45
   minute offsets, rather than Scheduling Core Object
     Specification.

     The value for the full 60 minute offset. Standard time "method" parameter is also known defined 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 follows:

        method  = <Identifier for
   all general time keeping.

3.21    Time Zone any IANA registered iCalendar
                   object method>

     Optional parameters: charset, component

     The particular time zone that time in a particular location "charset" parameter is
   expressed in. A time zone is unambiguously defined by in [RFC 2046] for other body
     parts. It is used to identify the default character set of time
   measurement rules determined by used within
     the governing body for the given
   location. These rules describe at a minimum part.

     The "component" parameter conveys the base offset from UTC,
   often referred to as type of iCalendar calendar
     component within the Standard Time offset. Optionally, if
   Daylight Savings Time is observed, body part. If the rules will specify iCalendar object contains
     more than one calendar component, then the
   Daylight Savings Time offset and either components are specified
     as a set comma-separated list of rules describing values.

     The value for the
   transition to and from Daylight Savings Time "component" parameter is defined as follows:

        component       = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
                        / x-token / iana-comp

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

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

     Optional content header fields: Any header fields defined by [RFC
     2045].

     Encoding considerations: This MIME content type can contain 8bit
     characters, so the movement in and out use of Daylight Savings Time. It is
   important quoted-printable or base64 MIME content-
     transfer-encodings MAY be necessary when iCalendar objects are
     transferrred across protocols restricted to note the 7bit repertoire.
     Note that these rules are not static. Time zones may each property in the content entity 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 even Aleutian Standard Time. Each of these are
   different offsets from UTC. Nevertheless, customary names for time
   zones are in use in various parts of
     characters encoded using a BACKSLASH character (ASCII decimal 92)
     escapement technique. This means that content values MAY end up
     encoded twice.

     Security considerations: SPOOFING - - In this memo, the world.

3.22    To-do


   A "Organizer"
     is the only person authorized to make changes to an existing
     "VEVENT", "VTODO", "VJOURNAL" calendar component that defines an action item and is minimally
   specified by redistribute
     the updates to the "Attendees". An iCalendar object that
     maliciously changes or cancels an effective existing "VEVENT", "VTODO" or
     "VJOURNAL" or "VFREEBUSY" calendar date component MAY be constructed by
     someone other than the "Organizer" and time sent to the "Attendees". In
     addition in this memo, an "Attendee" of day, a due "VEVENT", "VTODO",
     "VJOURNAL" calendar date and time of day, a priority and a description.

4.      TEXT/CALENDAR Registration Information


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

   The following text is intended only person authorized to register this specification as the
   MIME content type "text/calendar".

     To: ietf-types@uninett.no

     Subject: Registration of MIME content type text/calendar.

     MIME media type name: text

     MIME subtype name: calendar


Dawson/Stenerson                   9                   8                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

     Required parameters: profile

     The "profile"


     update any parameter is used associated with their "ATTENDEE" property and
     send it to convey the scheduling usage to
     which "Organizer". An iCalendar object that maliciously
     changes the calendaring and scheduling information pertains. It also
     is an identifier for "ATTENDEE" parameters MAY be constructed by someone
     other than the set of properties that real "Attendee" and sent to the "Organizer".

     PROCEDURAL ALARMS - - An iCalendar object will consist of. The parameter is intended to can be used as created that
     contains a
     guide "VEVENT" and "VTODO" calendar component with an "VALARM"
     calendar components. The "VALARM" calendar component MAY be of type
     PROCEDURE and MAY have an attachment containing some sort of
     executable program. Implementations that incorporate these types of
     alarms are subject to applications interpreting the information contained within any virus or malicious attack that MAY occur
     as a result of executing the body part. It attachment.

     ATTACHMENTS - - An iCalendar object MAY include references to
     Uniform Resource Locators that MAY be programmed resources.

     Implementers and users of this memo should NOT be used to exclude or require
     particular pieces aware of information unless the identified profile
     definition specifically calls network
     security implications of accepting and parsing such information. In
     addition, the security considerations observed by implementations
     of electronic mail systems should be followed for this behavior. Unless
     specifically forbidden by a particular profile definition, a
     text/calendar memo.

     Interoperability considerations: This MIME content type may contain any set of properties
     permitted by is intended
     to define a common format for conveying calendaring and scheduling
     information between different systems. It is heavily based on the
     earlier [VCAL] industry specification.

     Intended Usage: COMMON

     Published specification: This memo.

     Author/Change controllers:

        Frank Dawson
        6544 Battleford Drive
        Raleigh, NC 27613-3502
        919-676-9515 (Telephone)
        919-676-9564 (Data/Facsimile)
        Frank_Dawson@Lotus.com (Internet Mail)


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

4.      iCalendar Object Specification


   The following sections define the details of a Calendaring and
   Scheduling Core Object Specification.

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

        profile = component "-" usage

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

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

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

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

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

     Optional parameters: charset

     The "charset" parameter is defined in [RFC 2046] for other body
     parts. It is used intended to identify the default character set used within
   be an integral part of the body part.

     Optional content header fields: Any header fields defined by [RFC
     2045].

     Encoding considerations: This MIME content type can contain 8bit
     characters, so the use of quoted-printable or base64 MIME content-
     transfer-encodings may registration. In
   addition, this information MAY be necessary when iCalendar objects are
     transferrred across protocols restricted to the 7bit repertoire.
     Note that each property in the content entity may also have an
     inline encoding for the body part as a whole (i.e., inline encoding
     is performed first, then Content-Transfer-Encoding is applied to
     the entire body part). This means that used independent of such content values may end up
     encoded twice.



Dawson/Stenerson                   10                   9                   Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

     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.


   registration. In addition, particular, this information may contain memo has direct references to executable
     programs intended to be used as procedure-based alarms applicability for an event
     or to-do. Implementers
   use as a calendaring and users scheduling exchange format in file-, memory-
   or network-based transport mechanisms.

4.1     Content Considerations


   The iCalendar object consists of this specification should be
     aware lines of text. This section defines
   how the network security implications of accepting and parsing
     such information. In addition, the security considerations observed
     by implementations of electronic mail systems should be followed
     for this specification.

     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.

     Author/Change controllers:

        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)

5.      iCalendar Object Specification lines MUST be formatted.

4.1.1   Content Lines


   The following sections define the details iCalendar object consists of individual lines of text, delimited
   by a Calendaring and
   Scheduling Core Object Specification. This information line break, which is intended to
   be an integral part a CRLF sequence (ASCII decimal 13, followed
   by ASCII decimal 10). Line of the MIME content type registration. In
   addition, this information may text should not be used independent longer than 76
   characters, excluding the line break.

   Long lines of such content
   registration. In particular, this specification has direct
   applicability for use as text can be split into a calendaring and scheduling exchange format
   in file-, memory- or network-based transport mechanisms.

5.1     Syntax Considerations


   The content information associated with an iCalendar object is
   formatted multiple line representations
   using a syntax similar to that defined by [MIME DIR]. line "folding" technique. That is, a long line MAY be split
   at any point by inserting a CRLF immediately followed by a single
   LWSP character (i.e., SPACE, ASCII decimal 32 or HTAB, ASCII decimal
   9). Any sequence of CRLF followed immediately by a single LWSP
   character is ignored (i.e., removed) when processing the content
   type.

   For example the line:

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

   Can be represented as:

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

   The process of moving from this folded multiple line representation
   to its single line representation is called "unfolding". Unfolding is
   accomplished by removing the CRLF character and the LWSP character
   that immediately follows.

   An intentional formatted text line break MAY only be included in a
   property value by representing the line break with the character
   sequence of BACKSLASH (ASCII decimal 92), followed by a LATIN SMALL
   LETTER N (ASCII decimal 110) or a LATIN CAPITAL LETTER N (ASCII
   decimal 78), that is "\n" or "\N".

   For example a multiple line "DESCRIPTION" property value of:

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

   Could be represented as:





Dawson/Stenerson                   10                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DESCRIPTION:Project_XYZ Final_Review\n
      Conference Room - 3B\nCome_Prepared.

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

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

Dawson/Stenerson                   11              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
     ;Lines should be less than 76 characters, excluding CRLF.

     LWSP       = SPACE / HTAB

     SPACE      = <ASCII Decimal 32>

     HTAB       = <ASCII Decimal 9>

     name

     ws         = x-name SPACE / HTAB

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

     iana-name  = <One of the properties defined by this memo or
                   an IANA registered property, as defined by the
                   registration process in this memo.>

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

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

     paramlist atom. A non-standard
                   property name.>

     value      = parameter boolean / paramlist ";" parameter

     parameter  = encodingparm cal-address / valuetypeparm         ;If not present => inline value date / languageparm date-time / [parmtype "="] parmvalues

     encodingparm = "encoding" "=" encodetype

     encodetype = "8bit"        ;From [RFC 2045]
                / "7bit"        ;From [RFC 2045]
                / "q"           ;From [RFC 2045]
                / "b"           ;From [RFC 2045]

     valuetypeparm = "value" "=" valuetype

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

     iana-value = <A publicly <One of the property values defined extension value type, by this memo
                   or an IANA registered
                   with IANA, property value as specified defined by
                   the registration process in this document>

     languageparm = "language" "=" language
     ;As defined memo.>

4.1.2   List and Field Separators


   List of values MAY be specified for property values or property
   parameter values. Each value in [RFC 1766]

     parmtype   = x-token / iana-ptype

     iana-ptype = <A publicly defined extension a list of values MUST be separated by
   a COMMA character (ASCII decimal 44). A COMMA character in a property
   value or a property parameter type,
                   registered value MUST be escaped with IANA, as specified a BACKSLASH
   character (ASCII decimal 92).

   Some property values are defined in terms of multiple components.
   These structured property values MUST have their components separated
   by this document>

     parmvalues = parmvalue / parmvalues "," parmvalue a SEMICOLON character (ASCII decimal 59). A SEMICOLON character in
   a property value MUST be escaped with a BACKSLASH character (ASCII
   decimal 92).





Dawson/Stenerson                   12                   11                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

     parmvalue  = x-name / iana-pvalue

     iana-pvalue = <A publicly defined extension parameter value,
                    registered with IANA, as


   Lists of property parameters MAY be specified for a property. Each
   property parameter in a list of property parameters MUST be separated
   by this document> a SEMICOLON character (ASCII decimal 59). A SEMICOLON character in
   a property parameter value      = url / text / date / time / date-time / period /
                / duration / boolean / integer / float / cal-address
                / utc-offset / x-token / iana-value

     iana-value = <A publicly defined property value data type,
                   registered MUST be escaped with IANA, as defined in this document>

5.1.1   Content Lines


   Individual lines within the iCalendar object are delimited by a line
   break, which is a CRLF sequence BACKSLASH character
   (ASCII decimal 13, followed by ASCII 92).

   A COLON character (ASCII decimal 10). Line should not be longer than 76 characters, excluding
   the line break.

   Long lines of text can be split into a multiple-line representations
   using a line "folding" technique. That is, 58) in a long line may property parameter value
   MUST be split
   at any point by inserting a CRLF immediately followed by escaped with a single
   LWSP BACKSLASH character (i.e., SPACE, ASCII decimal 32 or HTAB, ASCII (ASCII decimal
   9). Any sequence of CRLF followed immediately by a single LWSP 92). A
   COLON character is ignored (i.e., removed) when processing the content
   type.

   For example the line:

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

   Can property value does not need to be represented as:

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

   The process of moving from this folded multiple-line representation
   to its single line representation is called "unfolding". Unfolding is
   accomplished by removing the CRLF character and the LWSP BACKSLASH character.

   A BACKSLASH character
   that immediately follows.

   An intentional formatted text line break (ASCII decimal 92) in a property value must
   also or a
   property parameter value MUST be specified by escaped with another BACKSLASH
   character.

   For example, in the following properties a (RFC 822) line break, which SEMICOLON is a CRLF
   sequence. However, since the CRLF sequence used to
   separate property parameters and property value fields. A COMMA is
   used to delimit a line, separate values.

     ATTENDEE;RSVP=TRUE;ROLE=ATTENDEE:J.Smith <jsmith@host.com>

     RDATE;VALUE=DATE:19970304,19970504,19970704,19970904

4.1.3   Multiple Values


   Each property values with imbedded formatted line breaks (i.e., hard line
   breaks) must be encoded using an alternate encoding of either the "Q"
   or "B" encodings, as defined in [RFC 2047]. These encodings are used
   directly and without any of the additional syntax elements of [RFC
   2047] encoded-words.

   Since neither the "Q" nor the "B" encodings ever produce LWSP
   characters (note that the "Q" encoding turns spaces into
   underscores), or CRLF character sequences as output, LWSP characters
   and CRLF character sequences can be freely inserted into encoded
   material at any point to fold encoded field values. All LWSP
   characters and CRLF character sequences should be ignored when


Dawson/Stenerson                   13              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   decoding an encoded field value. The "Q" encoding of iCalendar object MAY have multiple lines
   of formatted text are separated with a Q CRLF sequence of "=0D=0A".
   The length restrictions [RFC 2047] imposes on encoded-words do not
   apply
   values, if allowed in this context, but fields encoded with the "Q" or "B"
   encodings must be folded into lines definition of no longer than 76 characters.

   For example the specific property. The
   general rule for encoding multi-valued items is to simply create a multiple
   new content line DESCRIPTION for each value; including the property value of:

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

   Could name.
   However, it should be represented in "Q" noted that some properties support encoding as:

   DESCRIPTION;ENCODING=Q:Project_XYZ
    _Final_Review=0D=0A
    Conference_Room_-_3B=0D=0A
    Come_Prepared.

   And
   multiple values in the "B" encoding as:

   DESCRIPTION;ENCODING=UHJvamVjdCBYWVogRmluYWw
    gUmV2aWV3DQpDb25mZXJIbm NIIFJvb20gLSAzQg0KQ29tZ
    SBQcmVwYXJIZC4NCg = =

5.1.2   List and Field Separators


   Where a single property parameter value consists of a list of values, each
   value must be separated by separating the values with a
   COMMA character (ASCII decimal 44). A
   COMMA character in a property parameter value must

4.1.4   Binary Content


   There is no support for including binary content information, inline,
   within an iCalendar object. Binary content information MUST be escaped with a
   BACKSLASH character (ASCII decimal 92).

   Structured property values must have their components separated
   referenced by a
   SEMICOLON character (ASCII decimal 59). In addition, lists uniform resource locator (URL) type of property parameters must be separated by
   value.

   The following example specifies an "ATTACH" property with a SEMICOLON character (ASCII
   decimal 59). A SEMICOLON character in reference
   to an attachment consisting of a binary object:

     ATTACH:ftp://xyz.com/public/quarterly-report.doc

4.1.5   Property Parameters


   A property value or property
   parameter value must be escaped MAY have additional attributes associated with a BACKSLASH character (ASCII
   decimal 92).

   For example, in it. These
   "property parameters" contain meta information about the following properties a SEMICOLON is used to
   separate property parameters and or
   the property value fields. A COMMA is value. Property parameters MAY be used to separate values.

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

5.1.3   Multiple Values


   Each attribute or property defined in the iCalendar object may have
   multiple values, if allowed in specify the definition
   location of the specific
   property. The general rule an alternate text representation for encoding multi-valued items is to
   simply create a new content line for each value; including the property name. However, it should be noted that some properties
   support value,
   the content encoding multiple values in used on a single property by separating value, the values with language of a COMMA (ASCII decimal 44). text
   property value or thedata type of the property value.



Dawson/Stenerson                   14                   12                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

5.1.4   Character Set


   The default


   Property parameter values that contain the COLON, SEMICOLON, COMMA or
   BACKSLASH character set is [UTF-8]. separators MUST be specified as quoted-string
   text values. For transport in a MIME entity, example:

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas, NV, USA

   Property parameters are defined by the "charset" Content-Type following notation:

     (  = parameter may *(";" [ws] parameter)

     parameter  = altrepparm            ;Alterate text representation
                / languageparm          ;Text language
                / valuetypeparm         ;Property value data type
                / [parmtype "="] parmvalues ;Parameter extensions

     parmtype   = x-token / iana-ptype

     iana-ptype = <A publicly defined extension parameter type,
                   registered with IANA, as specified in this memo>

     parmvalues = parmvalue / parmvalue *("," [ws] parmvalue)

     parmvalue  = x-name / iana-pvalue

     iana-pvalue = <A publicly defined extension parameter value,
                    registered with IANA, as specified in this memo>

4.1.6   Alternate Text Representation


   The "ALTREP" property parameter is an OPTIONAL property parameter. It
   specifies the URL that points to an alternate representation for a
   textual property value. The property MUST include a value that
   reflects the default representation. This property parameter MAY
   include multiple values, separated by the COMMA character (ASCII
   decimal 44). The property parameter MAY only be used specified in the
   "COMMENT", "CONTACT", "DESCRIPTION", "LOCATION" and "SUMMARY"
   properties.

   For example:

     DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management

   The "ALTREP" property parameter value might point to set a "text/html"
   content portion.

     Content-Type:text/html
     Content-Id:<part3.msg.970415T083000@host.com>






Dawson/Stenerson                   13                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     <p><b>Project XYZ Review Meeting</b> will include the following
     agenda items:<li>Market
     Overview</li><li>Finances</li><li>Project Management</li></p>

   The "ALTREP" property parameter is defined by the following notation:

     altrepparm = "altrep" "=" urltype

     urltype    = <quoted-string text URL value>

4.1.7   Character Set


   There is not a property parameter to declare the character set used
   in a property value. The default character set for the entire an iCalendar
   object is [UTF-8].

   The "charset" Content-Type parameter MAY be used in MIME body part.

5.1.5 transports
   to specify any other IANA registered character set.

4.1.8   Language


   The "language" "LANGUAGE" property parameter should MAY be used to identify data in
   alternate languages. The default the
   language is "us-EN". used in text values. The value of the language "language" property
   parameter is that defined in [RFC 1766].

        Note: For transport in a MIME entity, the Content-Language
        header field may MAY be used to set the default language for the
        entire body part.

5.1.6   Content Encoding

   The "encoding" "LANGUAGE" property parameter should be used to specify an
   alternate encoding for a value. If is defined by the value contains following
   notation:

     languageparm =     "language" "=" language

     language = <Text identifying a <CR>
   character (ASCII decimal 10) or <LF> character (ASCII decimal 13), it
   must be encoded using either "Q" or "B" encoding, since <CR><LF> is
   used to separate lines in the iCalendar object itself.

5.1.7   Binary Content


   There is no support for inline encoding of binary information in an
   iCalendar object. Binary information is associated with the iCalendar
   object through the use of a uniform resource locator (URL) reference
   to the binary information.

5.1.8   Recurrence Set


   Recurring events and to-dos are supported by this specification. The
   recurrence within the iCalendar object may be specified as either a
   list of discrete date and time values or language, as a recurrence rule. The
   full recurrence set is generated by considering the initial DTSTART
   along with the RRULE, RDATE, EXDATE and EXRULE properties contained
   within the iCalendar object. The DTSTART defines the first instance
   in the recurrence set. Multiple instances of the RRULE and EXRULE
   properties may also be specified to define more sophisticated
   recurrence sets. The final recurrence set is generated by gathering
   all of the start date-times generated by any of the specified RRULE
   and RDATE properties, and excluding any start date and times which
   fall within the union of start date and times generated by any
   specified EXRULE and EXDATE properties. This implies that start date
   and times within exclusion related properties (i.e., EXDATE and
   EXRULE) take precedence over those specified by inclusion properties
   (i.e., RDATE and RRULE). Where duplicate instances are generated by
   the RRULE and RDATE specification, only one recurrence is considered.
   Duplicate instances are ignored.

   The recurrence rule used in the iCalendar object is defined in the
   RRULE component property.



Dawson/Stenerson                   15              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

5.1.9 [RFC 1766]>

4.1.9   Value Data Types


   The "value" "VALUE" property parameter is an optional OPTIONAL property parameter. It
   is used to identify the data type and format of the property value.
   The values of a given instance of a property must MUST only be of a single data type. For
   example, a RDATE "RDATE" property can not have a combination of DATE-TIME
   and TIME values.

   The following "VALUE" property parameter is defined by the following notation:

     valuetypeparm = "value" "=" valuetype

     valuetype  = "boolean"
                / "cal-address"
                / "date"
                / "date-time"
                / "duration"



Dawson/Stenerson                   14                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


                / "float"
                / "integer"
                / "period"
                / "recur"
                / "text"
                / "time"
                / "url"
                / "utc-offset"
                / x-token
                / iana-value

     iana-value = <A publicly defined extension value type, registered
                   with IANA, as specified by this memo>

   The following data types are used defined by
   the iCalendar object.

5.1.9.1 this memo.

4.1.9.1 Boolean


   The "boolean" "BOOLEAN" data type is used to identify properties that contain
   either a "true" or a "false" boolean value. These values are case
   insensitive. The data type is defined by the following notation:

     boolean    = "TRUE" / "FALSE"

   For example, any of the following are equivalent:

     TRUE
     true
     TrUe

5.1.9.2

4.1.9.2 Calendar User Address


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

     cal-address        = addr-spec / [phrase] phrase "<" addr-spec ">"

     addr-spec  = local-part "@" domain         ;RFC 822 style address
     local-part = WORD *("." WORD)
     domain     = domain-ref *("." domain-ref)
     domain-ref = ATOM

     phrase     = 1*WORD
     WORD       = ATOM / quoted-string
     quoted-string = <"> *(qtext/quoted-pair) <"> ; Regular qtext or
                                                  ;   quoted chars.
     qtext      = <any CHAR excepting <">,        ; => may MAY be folded
                  "\" & CR, and including linear-white-space> linear-
                  white-space>
     quoted-pair ="\" CHAR                        ; may MAY quote any char



Dawson/Stenerson                   15                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     CHAR       = <any a character from the
                  selected character set>
     ATOM       = 1*<any CHAR except specials,
                  SPACE and CTLs>

5.1.9.3

4.1.9.3 Date


   The "date" "DATE" data type is used to identify values that contain a
   calendar date. The format is expressed as the [ISO 8601] complete
   representation, basic format for a calendar date. The text format
   specifies a four-digit year, two-digit month, and two-digit day of
   the month. There are no separator characters between the year, month


Dawson/Stenerson                   16              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   and day component text. The data type is defined by the following
   notation:

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

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

     date               = date-fullyear date-month date-mday

   For example, the following represents July 14, 1997:

     19970714

5.1.9.4

4.1.9.4 Date-Time


   The "date-time" "DATE-TIME" data type is used to identify values that contain a
   precise calendar date and time of day. The format is expressed as the
   [ISO 8601] complete representation, basic format for a calendar date
   and time of day. The text format is a concatenation of the "date",
   followed by the LATIN CAPITAL LETTER T character (ASCII decimal 84)
   time designator, followed by the "time" format defined above. The
   data type is defined by the following notation:

     date-time  = date "T" time ;As specified above in date and time

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

     19970714T133000Z
     19970714T083000
     19970714T083000-0500

5.1.9.5
     19970714T083000-0400

4.1.9.5 Duration


   The "duration" "DURATION" data type is used to identify properties that contain
   a duration of time. The format is expressed as the [ISO 8601] basic
   format for the duration of time. The format can represent durations



Dawson/Stenerson                   16                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   in terms of years, months, days, hours, minutes, and seconds. The
   data type is defined by the following notation:

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

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

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

Dawson/Stenerson                   17              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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

   For example, a duration of 10 years, 3 months, 15 days, 5 hours, 30
   minutes and 20 seconds would be:

     P10Y3M15DT5H30M20S

5.1.9.6

4.1.9.6 Float


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

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

     float      = ["+" / "-"] *DIGIT ["." *DIGIT]

   For example:

     1000000.0000001
     1.333
     -3.14

5.1.9.7

4.1.9.7 Integer


   The "integer" "INTEGER" data type is used to identify properties that contain a
   signed integer value. The valid range for "integer" is -2147483648 to
   2147483647. If the sign is not specified, then the value is assumed
   to be positive. If the property permits, multiple "integer" values
   may
   MAY be specified using a COMMA character (ASCII decimal 44) separator
   character. The data type is defined by the following notation:

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

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



Dawson/Stenerson                   17                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   For example:

     1234567890
     -1234567890
     +1234567890
     432109876

5.1.9.8

4.1.9.8 Period of Time


   The "period" "PERIOD" data type is used to identify values that contain a
   precise period of time. There are two forms of a period of time.

   A period of time may MAY be identified by it start and its end. This
   format is expressed as the [ISO 8601] complete representation, basic
   format for "date-time" "DATE-TIME" start of the period, followed by a SOLIDUS
   character (ASCII decimal 47), followed by the "date-time" "DATE-TIME" of the end
   of the period. For example, the period starting at 10 AM in Seattle


Dawson/Stenerson                   18              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   (eight hours behind UTC) on January 1, 1997 and ending at 11 PM in
   Seattle on January 1, 1997 would be:

     19970101T100000-0800/19970101T230000-0800

   A period of time may MAY also be defined by a start and a duration of
   time. The format is expressed as the [ISO 8601] complete
   representation, basic format for the "date-time" "DATE-TIME" start of the period,
   followed by a SOLIDUS character (ASCII decimal 47), followed by the
   [ISO 8601] basic format for "duration" "DURATION" of the period. For example,
   the period start at 10 AM in Seattle (eight hours behind UTC) on
   January 1, 1997 and lasting 5 hours and 30 minutes would be:

     19970101T100000-0800/P5H30M

     19970101T100000-0800/PT5H30M

   The data type is defined by the following notation:

     period-explicit = date-time "/" date-time
     ;ISO 8601 complete representation basic format for a period of time
     ;consisting of a start and end. The start must MUST be before the end.

     period-start = date-time "/" duration
     ;ISO 8601 complete representation basic format for a period of time
     ;consisting of a start and duration of time.

     period     = period-explicit / period-start

5.1.9.9 Text

4.1.9.9 Recurrence Rule


   The "text" "RECUR" data type is used to identify values properties that contain human
   readable text. The character set and language in which the text is
   represented is controlled by the charset and language property
   parameters. a
   recurrence rule specification. The data type is a structured value
   consisting of a list of one or more recurrence grammar components.
   Each component is defined by a NAME=VALUE pair. The components are
   separated from each other by the following notation:

     CHAR       = <Any character in the selected SEMICOLON character set>

5.1.9.10        Time (ASCII decimal
   59). The "time" data type is used to identify values that contain a time
   of day. components are not ordered in any particular sequence.
   Individual components MAY only be specified once.



Dawson/Stenerson                   18                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The format is expressed as FREQ component identifies the [ISO 8601] complete
   representation, basic format for a time of day. The text format
   consists of a two-digit 24-hour type of the day (i.e., values 0-23), two-
   digit minute in the hour (i.e., values 0-59), and two-digit seconds recurrence rule. This
   component MUST be specified in the minute (i.e., recurrence rule. Valid values 0-59). If seconds
   include MINUTELY, to specify repeating events based on an interval of the
   a minute are not
   supported by or more; HOURLY, to specify repeating events based on an implementation, then a value
   interval of "00" should be
   specified for the seconds component. Fractions an hour or more; DAILY, to specify repeating events based
   on an interval of a day or more; WEEKLY, to specify repeating events
   based on an hour, minute interval of a week or
   second are not supported by this format. This format is used more; MONTHLY, to
   represent local time, local time with UTC offset and UTC time. UTC
   time is identified by specify repeating
   events based on an interval of a LATIN CAPITAL LETTER Z suffix character
   (ASCII decimal 90), the UTC designator, appended month or more; and YEARLY, to the time.
   specify repeating events based on an interval of a year or more.

   The
   local time with UTC offset is expressed as INTERVAL component contains a local time, suffixed
   with positive integer representing how
   often the signed offset from UTC. recurrence rule repeats. The UTC offset default value is express as the 2-
   digit hours "1" or every
   minute for a MINUTELY rule, every hour for a HOURLY rule, every day
   for a DAILY rule, every week for a WEEKLY rule, every month for a
   MONTHLY rule and 2-digit minutes difference from UTC. It every year for a YEARLY rule.

   The UNTIL component defines a date-time value which bounds the
   recurrence rule in an inclusive manner. If the value specified by
   UNTIL is expressed
   as positive, synchronized with an optional leading PLUS SIGN the specified recurrence, this date-time
   becomes the last instance of the recurrence. If not present, and the
   COUNT component is also not present, the RRULE is considered to
   repeat forever.

   The COUNT component defines the number of occurrences at which to
   range-bound the recurrence. This component is ignored if the "UNTIL"
   component is also present.

   The BYMINUTE component specifies a COMMA character (ASCII decimal 43), if the local time 44)
   separated list of minutes within an hour. Valid values are 0 to 60.
   Zero is ahead the beginning of UTC. It the hour and 60 is expressed as a
   negative, with the beginning of the next
   hour.

   The BYHOUR component specifies a leading HYPEN-MINUS COMMA character (ASCII decimal 45), if

Dawson/Stenerson                   19              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997 44)
   separated list of hours of the local time day. Valid values are 0 to 24. Zero is behind UTC. Local time has neither
   the UTC
   designator nor start of the UTC offset suffix text. The data type day and 24 is defined
   by the following notation:

     DIGIT      =<any ASCII start of the next day.

   The BYDAY component specifies a COMMA character (ASCII decimal digit>      ;0-9

     time-hour          = 2DIGIT        ;00-23
     time-minute        = 2DIGIT        ;00-59
     time-second        = 2DIGIT        ;00-59 44)
   separated list of days of the week; MO, indicates Monday; TU,
   indicates Tuesday; WE, indicates Wednesday; TH, indicates Thursday;
   FR, indicates Friday; SA, indicates Saturday; SU, indicates Sunday.

   Each BYDAY values MAY also be preceded by a positive (+n) or negative
   (-n) integer. If present, this indicates the nth occurrence of the
   specific day within the MONTHLY or YEARLY RRULE. For example, within
   a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
   within the month, whereas -1MO represents the last Monday of the
   month. If an integer modifier is not present, it means all days of
   this type within the specified frequency. For example, within a
   MONTHLY rule, MO represents all Mondays within the month.

   The BYMONTHDAY component specifies a COMMA character (ASCII decimal
   44) separated list of days of the month. Valid values are 1 to 31 or
   -31 to -1.



Dawson/Stenerson                   19                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   Each BYMONTHDAY value MAY be preceeded by a postive (+n) or negative
   (-n) integer. If present, this indicates the nth occurrence of the
   specific day of the month within the MONTHLY rule. If an integer
   modifier is not present, it means all days of this type within the
   specified frequency. For example, within a MONTHLY rule, -10
   represents the tenth to the last day of the month.

   The BYYEARDAY component specifies a COMMA character (ASCII decimal
   44) separated list of days of the year. Valid values are 1 to 366 or
   -366 to -1. For example, -1 represents the last day of the year
   (December 31st).

   The BYWEEKNO component specifies a comma-separated list of weeks of
   the year. Valid values are 1 to 53. This corresponds to weeks
   according to week numbering as defined in [ISO 8601]. That is, a week
   as "A seven day period within a calendar year, starting on a Monday
   and identified by its ordinal number within the year; the first
   calendar week of the year is the one that includes the first Thursday
   of that year." This component is only valid for YEARLY rules.

   Each BYWEEKNO value MAY be preceded by a positive (+n) or negative (-
   n) integer. If present, this indicates the nth occurrence of the
   specific week of the year within the YEARLY rule. If an integer
   modifier is not present, it means all days of this type within the
   specified frequency. For example, within a YEARLY rule, 3 represents
   the third week of the year.

   The BYMONTH component specifies a comma separated list of months of
   the year. Valid values are 1 to 12.

   The WKST component specifies the day on which the workweek starts.
   Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant
   when a WEEKLY RRULE has an interval greater than 1, and a BYDAY
   component is specified. The default value is MO.

   The BYSETPOS component specifies a COMMA character (ASCII decimal 44)
   separated list of values which corresponds to the nth occurrence
   within the set of events specified by the rule. Valid values are 1 to
   366 or -366 to -1. It MUST only be used in conjunction with another
   Byxxx component. For example "the last work day of the month" could
   be represented as:

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

   If BYxxx component values are found which are beyond the available
   scope (ie, BYMONTHDAY=-30 in February), they are simply ignored

   Information, not contained in the rule, necessary to determine the
   various recurrence instance start time and dates are derived from the
   Start Time (DTSTART) entry attribute. For example,
   ‘   ‘FREQ=YEARLY;BYMONTH=1’
                          ’ doesn’t specify a specific day within the
   month or a time. This information would be the same as what is
   specified for DTSTART.



Dawson/Stenerson                   20                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   BYxxx components modify the recurrence in some manner. BYxxx
   components for a period of time which is the same or greater than the
   frequency generally reduce or limit the number of occurrences of the
   recurrence generated. For example, ‘                                      ‘FREQ=DAILY;BYMONTH=1’
                                                            ’ reduces
   the number of recurrence instances from all days (if BYMONTH tag is
   not present) to all days in January. BYxxx components for a period of
   time less than the frequency generally increase or expand the number
   of occurrences of the recurrence. For example,
   ‘   ‘FREQ=YEARLY;BYMONTH=1,2’
                            ’ increases the number of days within the
   yearly recurrence set from 1 (if BYMONTH tag is not present) to 2.

   If only one BYxxx component is specified in the recurrence rule, the
   list of ‘           ‘n’
              ’ unique values would cause ‘
                                           ‘n’
                                              ’ occurrences of the
   recurrence within each specified frequency interval, where each
   unique list value is substituted in the appropriate date position
   within DTSTART for each such occurrence.

   If multiple BYxxx components are specified, then the list of ‘                                                                ‘n’
                                                                   ’
   unique values for each lower frequency BYxxx components is applied to
   the list of ‘               ‘n’
                  ’ unique values for higher frequency BYxxx
   components. This process will not always increase the set of
   occurrences. If a higher component is inconsistent with what was
   generated for lower components, it would reduce the set. The ordering
   of BYxxx components from lower frequency to higher frequency is as
   follows: BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, BYYEARDAY, BYWEEKNO,
   BYMONTH, BYSETPOS.

   Here is an example of evaluating multiple BYxxx components.

     ‘     ‘FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;BYMINUTE=30
     ’     ’

   would first apply the ‘                         ‘BYMINUTE=30’
                                      ’ To ‘
                                            ‘BYHOUR=8,9’
                                                        ’ to arrive at
   ‘   ‘every 8:30AM and 9:30AM’
                            ’. This in turn would be applied to
   ‘   ‘BYDAY=SU’
             ’ to arrive at ‘
                             ‘every Sunday at 8:30AM and 9:30AM’
                                                                ’. This
   would be applied to ‘                       ‘BYMONTH=1’
                                  ’ to arrive at ‘
                                                  ‘every Sunday in
   January at 8:30AM and 9:30AM’                               ’. Considering the FREQUENCY and
   INTERVAL, this would become ‘                               ‘Every Sunday in January at 8:30AM and
   9:30AM, every other year’                           ’. If the BYMINUTE, BYDAY, BYMONTHDAY,
   BYYEARDAY, BYHOUR or BYMONTH component was missing, the appropriate
   mintues, hour, day or month would have been retrieved from DTSTART.

   The data type is defined by the following notation:

     recur      = ‘                  ‘FREQ’
                        ’=freq ";"
                [("UNTIL" "=" enddate ";") / ("COUNT" "=" digits ";")]
                ["INTERVAL" "=" digits ";"]
                ["BYMINUTE" "=" byminlist ";"]
                ["BYHOUR" "=" byhrlist ";"]
                ["BYDAY" "=" bywdaylist ";"]
                ["BYMONTHDAY" "=" bymodaylist ";"]
                ["BYYEARDAY" "=" byyrdaylist ";"]
                ["BYWEEKNO" "=" bywknolist ";"]
                ["BYMONTH" "=" bymolist ";"]


Dawson/Stenerson                   21                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


                ["BYSETPOS" "=" bysplist ";"]
                ["WKST" "=" weekday ";")]
                *("X-" word "=" word) ";"
        ;Individual components MAY only be specified once.
        ;Rule components need not be specified in particular any order.

     freq       = "MINUTELY’                           ’ / "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY"

     enddate    = date          ;A UTC value

     digits     = 1*DIGIT

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

     byminlist  = minutes / ( minutes *(‘                                        ‘,’
                                           ’ minutes) )

     minutes    = 1*2digits     ;0 to 60

     byhrlist   = hour / ( hour *(‘                                  ‘,’
                                     ’ hour) )

     hour       = 1*2 digits    ;0 to 24

     bywdaylist = weekdaynum / ( weekdaynum *(‘                                              ‘,’
                                                 ’ weekdaynum) )

     weekdaynum = [([plus] ordwk / minus ordwk)] weekday

     plus       = "+"

     minus      = "-"

     ordwk      = 1*2digits     ;1 to 53

     weekday    = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
     ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
     ;FRIDAY, SATURDAY and SUNDAY days of the week.

     bymodaylist = monthdaynum / ( monthdaynum *(‘                                                 ‘,’
                                                    ’ monthdaynum) )

     monthdaynum = ([plus] ordmoday) / (minus ordmoday)

     ordmoday   = 1*2digits     ;1 to 31

     byyrdaylist = yeardaynum / ( yeardaynum *(‘                                               ‘,’
                                                  ’ yeardaynum) )

     yeardaynum = ([plus] ordyrday) / (minus ordyrday)

     ordyrday   = 1*3digits     ;1 to 366

     bywknolist = weeknum / ( weeknum *(‘                                        ‘,’
                                           ’ weeknum) )

     weeknum    = ([plus] ordwk) / (minus ordwk)

     bymolist   = monthnum / ( monthnum *(‘                                          ‘,’
                                             ’ monthnum) )



Dawson/Stenerson                   22                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     monthnum   = 1*2digits     ;1 to 12

     bysplist   = setposday / ( setposday *("," setposday) )

     setposday  = yeardaynum

   For example, the following is a rule which specifies 10 meetings
   which occur every other day:

     FREQ=DAILY;COUNT=10;INTERVAL=2

   There are other examples specified in the "RRULE" specification.

4.1.9.10        Text


   The "TEXT" data type is used to identify values that contain human
   readable text. The character set and language in which the text is
   represented is controlled by the "LANGUAGE" property parameters. The
   data type is defined by the following notation:

     text       = <Any character in the selected character set, but
                   not including CRLF>

4.1.9.11        Time


   The "TIME" data type is used to identify values that contain a time
   of day. The format is expressed as the [ISO 8601] complete
   representation, basic format for a time of day. The text format
   consists of a two-digit 24-hour of the day (i.e., values 0-23), two-
   digit minute in the hour (i.e., values 0-59), and two-digit seconds
   in the minute (i.e., values 0-59). If seconds of the minute are not
   supported by an implementation, then a value of "00" should be
   specified for the seconds component. Fractions of an hour, minute or
   second are not supported by this format. This format is used to
   represent local time, local time with UTC offset and UTC time. UTC
   time is identified by a LATIN CAPITAL LETTER Z suffix character
   (ASCII decimal 90), the UTC designator, appended to the time. The
   local time with UTC offset is expressed as a local time, suffixed
   with the signed offset from UTC. The UTC offset is express as the 2-
   digit hours and 2-digit minutes difference from UTC. It is expressed
   as positive, with an OPTIONAL leading PLUS SIGN character (ASCII
   decimal 43), if the local time is ahead of UTC. It is expressed as a
   negative, with a leading HYPEN-MINUS character (ASCII decimal 45), if
   the local time is behind UTC. Local time has neither the UTC
   designator nor the UTC offset suffix text. The data type is defined
   by the following notation:

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

     time-hour          = 2DIGIT        ;00-23
     time-minute        = 2DIGIT        ;00-59
     time-second        = 2DIGIT        ;00-59




Dawson/Stenerson                   23                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     time-numzone       = ("+" / "-") time-hour time-minute
     time-zone          = "Z" / time-numzone

     time               = time-hour time-minute time-second [time-zone]

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

     083000
     083000-0500
     133000Z

   There are cases when a floating time is intended within a property
   value. For example, an event may MAY be defined that indicates that an
   individual will be busy from 11:00 AM to 1:00 PM every day. In these
   cases, a local time may MAY be specified. The recipient of an iCalendar
   object with a property value consisting of a local time, without any
   relative time zone information, should interpret the value as being
   fixed to the recipient's locale and time zone. In most cases, a fixed
   time is desired. To properly communicate a fixed time in a property
   value, either UTC, local time with UTC offset, or local time with a
   time zone
   "VTIMEZONE" calendar component must MUST be specified.

5.1.9.11

4.1.9.12        URL


   The "url" "URL" data type is used to identify values that contain a uniform
   resource locator (URL) type of reference to the property value. This
   data type might be used to reference binary information, for values
   that are large, or otherwise undesirable to include directly in the
   iCalendar object.

   The URL value formats in RFC 1738, RFC 2111 and any other IETF
   registered value format may MAY be specified.

   The data type is defined by the following notation:

     url        = <As defined by any IETF RFC>

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

   For example, the following is an URL for a local file:

     file:///my-report.txt



Dawson/Stenerson                   20              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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

5.1.9.12

4.1.9.13        UTC Offset


   The "utc -offset" "UTC-OFFSET" data type is used to identify properties that
   contain an offset from UTC to local time. The data type is defined by
   the following notation:




Dawson/Stenerson                   24                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     utc-offset = time-numzone  ;As defined above in time data type

   For example, the following are UTC offsets are given for standard
   time for New York (five hours behind UTC) and Geneva (one hour ahead
   of UTC):

     -0500      ;New York

     +0100      ;Geneva

5.2

4.2     iCalendar Object object


   The Calendaring and Scheduling Core Object is a collection of
   calendaring and scheduling information. Typically, this information
   will consist of a single iCalendar object. However, multiple
   iCalendar objects may MAY be sequentially, grouped together. The first
   line and last line of the iCalendar object must MUST contain a pair of
   iCalendar object delimiter strings. The syntax for an iCalendar
   object is as follows:

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

   The following is a simple example of an iCalendar object:

     BEGIN:VCALENDAR
     VERSION:2.0
     PRODID:-//hacksw/handcal//NONSGML v1.0//EN
     BEGIN:VEVENT
     DTSTART:19970714T120000-0500
     DTEND:19970714T235959-0500
     DESCRIPTION:Bastille
     SUMMARY:Bastille Day Party
     END:VEVENT
     END:VCALENDAR

5.3

4.3     Property


   A property is the definition of an individual attribute describing a
   calendar property or a calendar component. A property takes the
   following form:

     property   = propname [";" [ws] parmlist] ":" [ws] value CRLF

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

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

Dawson/Stenerson                   21              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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




Dawson/Stenerson                   25                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The following is an example of a property:

     DTSTART:19960415T083000-05:00

   This document memo places no imposed ordering of properties within an
   iCalendar object.

   Property names, parameter names and parameter values (i.e.,
   everything to the left of the ":" on a line) are case insensitive.
   For example, the property name "DUE" is the same as "due" and "Due".

5.4

4.4     Calendar Components


   The body of the iCalendar object consists of a sequence of calendar
   properties and one or more calendar components. The calendar
   properties are attributes that apply to the calendar as a whole. The
   calendar components are collections of properties that with a
   particular calendar semantic. For example, the calendar component may MAY
   specify a an event, a to-do, journal entry, time zone information, or
   free/busy time information, or alarm.

   The body of the iCalenar Object is defined by the following notation:

     icalbody   = calprops 1*component

     calprops   = [calscale] prodid [profile] [profile-version] method [source] [name] version

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

5.4.1

4.4.1   Event Component


   An Event Calendar Component


   A "VEVENT" calendar component is a grouping of component properties
   and an optional alarm OPTIONAL "VALARM" calendar component that represent a
   scheduled amount of time on a calendar. For example, it may MAY be an
   activity; such as a one-hour, department meeting from 8:00 AM to 9:00
   AM, tomorrow.

   An Event Component Generally, these events will take up time on an
   individual calendar. Hence, the event will appear as an opaque
   interval in a search for busy time. Alternately, the event MAY have
   its Time Transparency set to "TRANSPARENT" in order to prevent
   blocking of the event in searches for busy time.

   The "VEVENT" is also the calendar component used to specify an
   anniversary or daily reminder within a calendar. These events have a
   start time but no end time. The start time MAY also be specified as a
   DATE value data type, instead of the default DATE-TIME.

   A "VEVENT" calendar component is defined by the following notation:

     eventc     = "BEGIN" ":" [ws] "VEVENT" CRLF
                  *eventprop
                  eventprop *alarmc
                  "END" ":" [ws] "VEVENT" CRLF




Dawson/Stenerson                   26                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     eventprop  = *attach *attendee *categories [class] *comment
                  *contact [created]
                  description [dtend] [description] [dtend / duration]
                  dtstart *exdate *exrule [geo] *last-mod [last-mod] [location]
                  [priority] [rstatus] *related *resources *rdate
                  *rrule dtstamp
                  [resp-seq] [seq] [status] [summary] summary [transp] uid
                  *url [recurid] *(comment)



Dawson/Stenerson                   22              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The Event Component "VEVENT" calendar component can not be nested within another Calendar
   Component. Event
   calendar component. The "VEVENT" calendar components may MAY be related
   to each other or to a To-
   do "VTODO" or Journal Calendar Component "VJOURNAL" calendar component with
   the RELATED-TO "RELATED-TO" property.

   The following is an example of the Event Calendar Component: "VEVENT" calendar component used
   to represent a meeting that will also be opaque to searches for busy
   time:

     BEGIN:VEVENT
     UID:19970901T130000Z-123401@host.com
     DTSTAMP:19970901T1300Z
     DTSTART:19970903T083000-0800
     DTEND:19970903T110000-0800
     DESCRIPTION:Annual
     SUMMARY:Annual Employee Review
     CLASS:PRIVATE
     CATEGORIES:BUSINESS,HUMAN RESOURCES
     END:VEVENT

5.4.2

   The following is an example of the "VEVENT" calendar component used
   to represent a reminder that will not be opaque, but rather
   transparent, to searches for busy time:

     BEGIN:VEVENT
     UID:19970901T130000Z-123402@host.com
     DTSTAMP:19970901T1300Z DTSTART:19970401T083000-0800
     DTEND:19970401T170000-0800
     SUMMARY:Laurel is in sensitivity awareness class.
     CLASS:PUBLIC
     CATEGORIES:BUSINESS,HUMAN RESOURCES
     TRANSP:TRANSPARENT
     END:VEVENT

   The following is an example of the "VEVENT" calendar component used
   to represent an anniversary that will occur annually. Since it takes
   up no time, it will not appear as opaque in a search for busy time;
   no matter what the value of the "TRANSP" property indicates:

     BEGIN:VEVENT
     UID:19970901T130000Z-123403@host.com
     DTSTAMP:19970901T1300Z
     DTSTART:19971102
     SUMMARY:Our Blissful Anniversary
     CLASS:CONFIDENTIAL
     CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
     RRULE:FREQ=YEARLY
     END:VEVENT


Dawson/Stenerson                   27                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


4.4.2   To-do Component


   A To-do Calendar Component "VTODO" calendar component is a grouping of component properties
   and an optional alarm OPTIONAL "VALARM" calendar component that represent an action-item action-
   item or assignment. For example, it may MAY be an item of work assigned
   to an individual; such as "turn in travel expense today".

   A To-do Component "VTODO" calendar component is defined by the following notation:

     todoc      = "BEGIN" ":" [ws] "VTODO" CRLF
                  *todoprop
                  todoprop *alarmc
                  "END" ":" [ws] "VTODO" CRLF

     todoprop   = *attach *attendee *categories [class] *comment
                  [completed] *contact [created] description [description] dtstamp
                  dtstart due [due / duration] *exdate *exrule [geo] *last-mod
                  [last-mod] [location] [percent] priority [rstatus]
                  *related *resources *rdate *rrule [resp-seq] [recurid] [seq]
                  [status] [summary] [transp] summary uid *url *(comment)

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

   The following is an example of a To-do Calendar Component: "VTODO" calendar component:

     BEGIN:VTODO
     UID:19970901T130000Z-123404@host.com
     DTSTAMP:19970901T1300Z
     DTSTART:19970415T083000-0500
     DUE:19970415T235959-0500
     DESCRIPTION:1996
     SUMMARY:1996 Income Tax Preparation
     CLASS:CONFIDENTIAL
     CATEGORIES:FAMILY,FINANCE
     PRIORITY:1
     STATUS:NEEDS ACTION
     STATUS:NEEDS-ACTION
     END:VEVENT

5.4.3

4.4.3   Journal Component


   A Journal Calendar Component "VJOURNAL" calendar component is a grouping of component properties
   that represent one or more descriptive text notes on a particular particular
   calendar date. The "DTSTART" property is used to specify the calendar
   date that the journal entry is associated with. Generally, it will
   have a DATE value data type, but it MAY also be used to specify a
   DATE-TIME value data type. Examples of a journal entry include a
   daily record of a legislative body or a journal entry of individual
   telephone contacts for the day or an ordered list of accomplishments
   for the day. The calendar component can also be used to associate a
   document with a calendar date. For example, it may be a journal entry of individual telephone





Dawson/Stenerson                   23                   28                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

   contacts for the day


   The "VJOURNAL" calendar component does not take up time on a
   calendar. Hence, it does not play a role in free or an ordered list busy time
   searches - - it is as though it has a time transparency value of accomplishments for the
   day.
   TRANSPARENT. It is transparent to any such searches.

   A Journal Component "VJOURNAL" calendar component is defined by the following notation:

     journalc   = "BEGIN" ":" [ws] "VJOURNAL" CRLF
                  *jourprop
                  jourprop
                  "END" ":" [ws] "VJOURNAL" CRLF

     jourprop   = *attach *attendee *categories [class] *comment
                  *contact [created]
                  description [description] dtstart dtstamp *last-mod
                  *exdate *exrule [last-mod] *related
                  [rdate] [rrule] *rdate *rrule
                  [rstatus] [resp-seq] [seq] summary uid *url [recurid] *(comment)

   The Journal Component "VJOURNAL" calendar component can not be nested within another Calendar
   Component.
   calendar component. If Journal Components "VJOURNAL" calendar components need to be
   related to each other or to an Event a "VEVENT" or To-Do Calendar Component, "VTODO" calendar component,
   they can specify a relationship with the RELATED-TO "RELATED-TO" property.

   The following is an example of the Journal Calendar Component: "VJOURNAL" calendar component:

     BEGIN:VJOURNAL
     DTSTART:19970317T083000
     UID:19970901T130000Z-123405@host.com
     DTSTAMP:19970901T1300Z
     DTSTART;VALUE=DATE:19970317
     SUMMARY:Staff meeting minutes
     DESCRIPTION:1. Staff meeting: Participants include Joe, Joe\, Lisa
       and Bob. Aurora project plans were reviewed. There is currently
       no budget reserves for this project. Lisa will escalate to
       management. Next meeting on Tuesday.
       2. Telephone Conference: ABC Corp. sales representative called
       to discuss new printer. Promised to get us a demo by Friday.
       3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
       Is looking into a loaner car. 654-2323 (tel).
     END:VJOURNAL

5.4.4

4.4.4   Free/Busy Component


   A Free/Busy Calendar Component "VFREEBUSY" calendar component is a grouping of component
   properties that represent represents either a request for, or a reply with,
   free or busy time information. Typically, this component exists in an
   iCalendar object that is being used to either request or return free
   or busy time information.

   A Free/Busy Component "VFREEBUSY" calendar component is defined by the following
   notation:

     freebusyc  = "BEGIN" ":" [ws] "VFREEBUSY" CRLF
                  *fbprop
                  fbprop
                  "END" ":" [ws] "VFREEBUSY" CRLF




Dawson/Stenerson                   29                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     fbprop     = fbrequest / fbreply

     fbrequest  = *attendee [created] dtstart dtend [duration] [dtend] [dtstart] *comment dtstamp
                  [last-mod] *related [seq] uid
     ;This set of properties is used to for free/busy time request.

     fbreply    = *attendee [created] *comment [dtstart dtend] dtstamp #freebusy *last-mod
                  *freebusy [last-mod] *related [rstatus]
                  [resp-seq] [seq] uid *url *(comment)
     ;This set of properties is used for free/busy time reply.

   The Free/Busy Component "VFREEBUSY" calendar component can not be nested within another Calendar
   Component. Free/Busy
   calendar component. The "VFREEBUSY" calendar components may MAY be
   related to each other with the
   RELATED-TO "RELATED-TO" property. Multiple Free/Busy Calendar Components may
   "VFREEBUSY" calendar components MAY be specified within a iCalendar
   object. This permits the grouping of Free/Busy information into
   logical collections, such as monthly groups of busy time information.


Dawson/Stenerson                   24              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The Free/Busy Calendar Component "VFREEBUSY" calendar component is intended for use in profiles iCalendar
   object methods involving requests for free time, requests for busy
   time, requests for both free and busy, and the associated replies.

   Free/Busy information can be expressed using the FREEBBUSY "FREEBBUSY"
   property. This property provides a terse representation of time
   periods. One or more FREEBUSY "FREEBUSY" properties may MAY be specified in the FREE/BUSY Calendar
   Component
   "VFREEBUSY" calendar component to describe the Free/Busy information.

   Optionally, the DTSTART "DTSTART" and DTEND "DTEND" properties may MAY be specified to
   express the start and end date and time for all of the Free/Busy
   information in the Free/Busy Calendar Component. "VFREEBUSY"calendar component. When present in a Free/Busy
   Calendar Component,
   "VFREEBUSY" calendar component, they should be specified prior to any FREEBUSY
   "FREEBUSY" properties. In a free time request, these properties may MAY
   be used in combination with the DURATION "DURATION" property to express a
   request for a duration of free time within a given window of time.

   The recurrence properties (RRULE, EXRULE, RDATE, EXDATE) ("RRULE", "EXRULE", "RDATE", "EXDATE") are
   not permitted within a Free/Busy Calendar Component. "VFREEBUSY" calendar component. Any recurring
   events are resolved into their individual busy time periods using the
   FREEBUSY
   "FREEBUSY" property.

   The following is an example of a Free/Busy Calendar Component: "VFREEBUSY" calendar component:

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

5.4.5   Alarm Component


   An
     FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,
      19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
     END:VFREEBUSY

4.4.5   Alarm Calendar Component


   A "VALARM" calendar component is a grouping of component properties
   that is a reminder or alarm for an event or a to-do. The Alarm
   Calendar Component may "VALARM"
   calendar component MAY only be specified in an event a "VEVENT" or to-do "VTODO"



Dawson/Stenerson                   30                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


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

   The DTSTART "DTSTART" property specifies the calendar date and time of day
   that the alarm will be triggered. The value may MAY alternately be set to
   a period of time, before or after the event or to-do, that the alarm
   will be triggered.

   An Alarm Component

   A "VALARM" calendar component is defined by the following notation:

     alarmc     = "BEGIN" ":" [ws] "VALARM" CRLF
                  *alarmprop
                  alarmprop
                  "END" ":" [ws] "VALARM" CRLF

     alarmprop  = *attach [created] 1*categories *comment [description]
                  dtstart duration
                / *last-mod *related repeat [summary] *(comment)

   The Alarm Component "VALARM" calendar component can only appear within either an Event a
   "VEVENT" or To-Do
   Calendar Component. Alarm Components "VTODO" calendar component. The "VALARM" calendar
   components can not be nested.



Dawson/Stenerson                   25              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The following is an example of the Alarm Calendar Component: "VALARM" calendar component:

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

5.4.6

4.4.6   Timezone Component


   The "VTIMEZONE" calendar component is used to define a time zone.

   A time zone is unambiguously defined by the set of time measurement
   rules determined by the governing body for a given geographic area.
   These rules describe at a minimum the base offset from UTC for the
   time zone, often referred to as the Standard Time offset. Many
   locations adjust their Standard Time forward or backward by one hour,
   in order to accommodate seasonal changes in number of daylight hours,
   often referred to as Daylight Saving Time. Some locations adjust
   their time by a fraction of an hour. Standard Time is also known as
   Winter Time. Daylight Saving Time is also known as Advanced Time,
   Summer Time, or Legal Time in certain countries. The following table
   shows the changes in time zone rules for the eastern United States.

     Effective  Transition Rule
     Date       (Date/Time)                 Offset   Abbreviation

     1920-1920 last Sun in Mar, 02:00  -0400    EDT




Dawson/Stenerson                   31                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     1920-1920 last Sun in Oct, 02:00  -0500    EST

     1921-1966 last Sun in Apr, 02:00  -0400    EDT

     1921-1954 last Sun in Sep, 02:00  -0500    EST

     1955-1966 last Sun in Oct, 02:00  -0500    EST

     1967-*     last Sun in Oct, 02:00  -0500    EST

     1967-1973  last Sun in Apr, 02:00  -0400    EDT

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

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

     1976-1986  last Sun in Apr, 02:00  -0400    EDT

     1987-*     first Sun in Apr, 02:00 -0400    EDT

   Interoperability between two calendaring and scheduling applications,
   especially for recurring events and to-dos, events, to-dos or journal entries, is
   dependent on the ability to capture and convey date and time
   information in an unambiguous format. The specification of current
   time zone information is integral to this behavior.



Dawson/Stenerson                   26              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The Time Zone Calendar Component "VTIMEZONE" calendar component is a grouping of component
   properties that define a time zone description. The time zone
   description specifies the effective Standard Time or Daylight Savings
   Time rules for a particular time zone. The Timezone Component "VTIMEZONE" calendar
   component can not be nested within other Calendar Components. calendar components. The Time Zone Component
   may
   "VTIMEZONE" calendar component MAY be specified multiple times. If
   the Time Zone Component "VTIMEZONE" calendar component is missing, the recipient should
   assume all local times are relative to the recipient's time zone. The Time Zone Component
   "VTIMEZONE" calendar component should be specified in the iCalendar
   object before any other Calendar
   Components. calendar components.

   A Time Zone Component "VTIMEZONE" calendar component is defined by the following
   notation:

     timezonec  = "BEGIN" ":" [ws] "VTIMEZONE" CRLF
                  *tzprop
                  tzprop
                  "END" ":" [ws] "VTIMEZONE" CRLF

     tzprop     = [created] *comment [daylight] dtstart [rdate / rrule]
                  [tzname] tzoffset *(comment)

   The Time Zone "VTIMEZONE" calendar component is important for correct
   interpretation of individual as well as recurring calendar components
   that span a time zone transition. For example, from EST to EDT.  The
   exception to this are calendar components that are considered
   floating (i.e., occurs at a particular local time no matter what time
   zone you are in). If the iCalendar object contains a non-floating
   calendar component that has a recurring date pattern (i.e., includes


Dawson/Stenerson                   32                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   the RRULE "RRULE" property) or a list of date and local time values (i.e.,
   includes the RDATE "RDATE" property), one or more Time Zone "VTIMEZONE" calendar
   components must MUST be specified, such that for the given range of the
   recurrence (i.e., the earliest instance to latest instance), there is
   valid time zone information for all instances. In other words, if all
   of the instances of the pattern is entirely within one offset
   observance, (e.g., all are in Standard Time), only one Time Zone Calendar Component "VTIMEZONE"
   calendar component need be present. If a time zone transition is
   crossed, then other Time Zone
   Components "VTIMEZONE" calendar components are needed.
   Further, if there are known changes to the rules for the time zone,
   even more Time Zone Components "VTIMEZONE" calendar components are needed.

   Each Time Zone Component "VTIMEZONE" calendar component consists of several properties:

   The CREATED property is a DATE-TIME value that indicates when the
   time zone description was created.

   The DAYLIGHT "DAYLIGHT" property is a BOOLEAN value indicating Standard Time
   (FALSE) or Daylight Savings Time (TRUE). The default for DAYLIGHT is
   FALSE or Standard Time.

   The DTSTART "DTSTART" property in this usage is a fully specified DATE-TIME
   value, including the UTC offset, indicating the effective start date
   and time for the time zone information. For example, 19671029T020000-
   0400 represents the time at which the transition to Standard Time
   took effect in 1967 for the eastern United States.

   The TZOFFSET "TZOFFSET" property is a UTC-OFFSET value indicating the UTC
   offset for the time zone (Standard Time or Daylight Savings Time).

   The TZNAME property is the customary name for the time zone.

Dawson/Stenerson                   27              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The RRULE "TZNAME" property is a TEXT the customary name for the time zone.

   The "RRULE" property indicating indicates the recurrence rule for the transition
   to this time zone. For example, in the United States, the transition
   from Standard Time to Daylight Saving Time occurs on the first Sunday
   in April at 02:00. If a recurrence rule describing the transition is
   known to have an effective end date, the UNTIL recurrence rule
   parameter is used to specify that end date and time. If the
   recurrence rule for a particular observance (Daylight Saving Time) is
   changing, then the UNTIL of the first rule will be equal to the DTSTART for the replacement last
   valid instance (the last date-time) of this particular rule. See
   example below.

   Alternatively, the RDATE "RDATE" property can be used. The RDATE "RDATE" property
   is a DATE-TIME property indicating that indicates the individual dates and and/or times that
   the transition takes effect. The values supplied for RDATE "RDATE" property
   for each
   Time Zone "VTIMEZONE" calendar component must MUST provide valid time zone
   information of all instances of the recurrence specified for the
   calendar component to which this time zone information is to be
   applied.

   The following are examples of the Time Zone Calendar Component: "VTIMEZONE" calendar component:

   This is a simple example showing time zone information for the
   Eastern United States using RDATE. "RDATE" property. Note that this is only
   suitable for a recurring event that starts on or later than 1997,
   April 6, at 02:00:00 EST (i.e., the earliest effective transition


Dawson/Stenerson                   33                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   date and time) and ends no later than 1998, April 7, 02:00:00 EST
   (i.e., latest valid date and time for EST in this scenario).  For
   example, this can be used for a recurring event that ocurrs every
   Friday, 8am-9am, starting June 1, 1997, ending Dec 31, 1997.

     BEGIN:VTIMEZONE
     DAYLIGHT:FALSE
     RDATE:19971026T020000-0400
     TZOFFSET:-0500
     TZNAME:EST
     END:VTIMEZONE

     BEGIN:VTIMEZONE
     DAYLIGHT:TRUE
     RDATE:19970406T020000-0500
     TZOFFSET:-0400
     TZNAME:EDT
     END:VTIMEZONE

   This is a simple example showing the current time zone rules for the
   Eastern United States using a RRULE recurrence pattern. Note that
   there is no effective end date to either of the Standard Time or
   Daylight Time rules. This information would be valid for a
   recurrening event starting today and continuing on into the known
   future.

     BEGIN:VTIMEZONE
     DAYLIGHT:FALSE
     DTSTART:19671029T020000-0400
     RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
     TZOFFSET:-0500
     TZNAME:EST
     END:VTIMEZONE


Dawson/Stenerson                   28              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     BEGIN:VTIMEZONE
     DAYLIGHT:TRUE
     DTSTART:19870405T020000-0500
     RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY
     RRULE: FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
     TZOFFSET:-0400
     TZNAME:EDT
     END:VTIMEZONE

   This is an example showing a ficticious set of rules for the Eastern
   United States, where the Daylight Time rule has an effective end date
   (i.e., after that date, Daylight Time is no longer observed).

     BEGIN:VTIMEZONE
     DAYLIGHT:FALSE
     DTSTART:19671029T020000-0400
     RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
     TZOFFSET:-0500
     TZNAME:EST
     END:VTIMEZONE



Dawson/Stenerson                   34                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     BEGIN:VTIMEZONE
     DAYLIGHT:TRUE
     DTSTART:19870405T020000-0500
     RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY;UNTIL=19981025T020000-0400
     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T020000-0500
     TZOFFSET:-0400
     TZNAME:EDT
     END:VTIMEZONE

   This is an example showing a ficticious fictitious set of rules for the Eastern
   United States, where the first Daylight Time rule has an effective
   end date. There is a second Daylight Time rule that picks up where
   the other left off.

     BEGIN:VTIMEZONE
     DAYLIGHT:FALSE
     DTSTART:19671029T020000-0400
     RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
     TZOFFSET:-0500
     TZNAME:EST
     END:VTIMEZONE

     BEGIN:VTIMEZONE
     DAYLIGHT:TRUE
     DTSTART:19870405T020000-0500
     RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY;UNTIL=19990404T020000-0500
     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T020000-0500
     TZOFFSET:-0400
     TZNAME:EDT
     END:VTIMEZONE

     BEGIN:VTIMEZONE
     DAYLIGHT:TRUE
     DTSTART:19990404T020000-0500
     RRULE:BYDAY=-1SU;BYMONTH=3;FREQ=YEARLY
     DTSTART:19990327T020000-0500
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
     TZOFFSET:-0400
     TZNAME:EDT
     END:VTIMEZONE


Dawson/Stenerson                   29              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

5.5

4.5     Calendar Properties


   The Calendar Properties are attributes that apply to the iCalendar
   object, as a whole. These properties do not appear within a Calendar
   Component. calendar
   component. They should be specified after the BEGIN:VCALENDAR
   properties "BEGIN:VCALENDAR"
   property and prior to any Calendar Component.

5.5.1 calendar component.

4.5.1   Calendar Scale


   This property is identified by the property name CALSCALE. This
   property defines the calendar scale used for the calendar information
   specified in the iCalendar object. This specification memo is based on the
   Gregorian calendar scale. The Gregorian calendar scale is assumed if
   this property is not specified in the iCalendar object. It is
   expected that other calendar scales will be defined in other
   specifications or by future versions of this specification.

   The property is defined by the following notation:

     calscale   = "CALSCALE" ":" calvalue CRLF

     calvalue   = "GREGORIAN" / iana-scale

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

   The following is an example of this property:

     CALSCALE:GREGORIAN

   The data type for this property is TEXT.

5.5.2   Product Identifier


   This property is identified by the property name PRODID. This
   property specifies the identifier for the product that created the
   iCalendar 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. This calendar property must be specified in the
   iCalendar object but can only appear once. memo.



Dawson/Stenerson                   35                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The property is defined by the following notation:

     prodid     = "prodid" ":" pidvalue CRLF

     pidvalue   = text
     ;Any text that describes the product and version
     ;and that is generally assured of being unique. notation:

     calscale   = "CALSCALE" ":" [ws] calvalue CRLF

     calvalue   = "GREGORIAN" / iana-scale

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

   The following is an example of this property:

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

     CALSCALE:GREGORIAN

   The data type for this property is TEXT.



Dawson/Stenerson                   30              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

5.5.3   Profile

4.5.2   Method


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

   The property is defined by the following notation:

     profile

     method     = "PROFILE" "METHOD" ": [ws] profvalue CRLF

     profvalue  = " component "-" action

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

     action     = <Any IANA registered iCalendar action type.>

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

     iana-component = <Any other component registered with IANA> object method.>

   The following is an example of this property when the iCalendar
   object is used to request a meeting:

     PROFILE:EVENT-REQUEST

     METHOD: REQUEST

   In the event that this property is not specified, the usage profile iCalendar
   object method is undefined. The data type for this property is TEXT.

5.5.4   Profile Version

4.5.3   Product Identifier


   This property is identified by the property name PROFILE-VERSION. PRODID. This
   property specifies the identifier corresponding to for the highest
   version number or product that created the minimum and maximum range
   iCalendar object. The vendor of the usage profile implementation should assure that was used
   this is a globally unique identifier; using some technique such as an
   ISO 9070 FPI value. This calendar property MUST be specified in constructing the
   iCalendar object. Values for this object but can only appear once.

   This property are to should not be defined by registering used to alter the interpretation of an
   iCalendar usage
   profiles. object beyond the semantics specified in this memo. For
   example, it is not to be used to further the understanding of non-
   standard properties.

   The property is defined by the following notation:

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

     profvalue  = iana-prfver

     iana-prfver = max-prfver / (min-prfver ";" max-prfver)

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

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

   The following is an example of this property:



Dawson/Stenerson                   31                   36                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

     PROFILE-VERSION:IPCS-1.0


     prodid     = "PRODID" ":" [ws] pidvalue CRLF

     pidvalue   = text
     ;Any text that describes the product and version
     ;and that is generally assured of being unique.

   The following is an example of this property:

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

   The data type for this property is TEXT.

5.5.5

4.5.4   Source


   This property is identified by the property name SOURCE. This
   property is defined by the [MIME DIR] specification. memo. In this
   specification, memo, the
   property identifies the URL for the source of the iCalendar object.
   The URL is useful for accessing the iCalendar object using a calendar
   access protocol.

   The property is defined by the following notation:

     source     = "SOURCE" ":" [ws] url CRLF

   The following are examples of this property:

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

     SOURCE:http://xyz.corp.com/calendars/~jdoe

   The data type for this property is URL.

5.5.6

4.5.5   Source Name


   This property is identified by the property name NAME. This property
   is defined by the [MIME DIR] specification. memo. The property identifies the
   displayable, presentation name for the source of the iCalendar
   object. The source name is a useful text to associate in the user-
   interface of an application with the value in the SOURCE property.

   The property is defined by the following notation:

     name       = "NAME" ":" [ws] text CRLF

   The following is an example of this property:

     NAME:1997 Events Calendar for XYZ Corporation

   The data type for this property is TEXT.

5.5.7







Dawson/Stenerson                   37                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


4.5.6   Version


   This property is identified by the property name VERSION. This
   property specifies the identifier corresponding to the highest
   version number or the minimum and maximum range of the MIME
   Calendaring and Scheduling Content Type specification supported by
   the implementation that created the iCalendar object. A value of
   "2.0" corresponds to this specification. memo. This calendar property must MUST appear
   within the iCalendar object but can only appear once.

   The property is defined by the following notation:

     version    = "VERSION" ":" [ws] vervalue CRLF


Dawson/Stenerson                   32              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     vervalue   = "2.0"         ;This specification memo
                / maxver
                / (minver ";" [ws] maxver)

     minver     = <A IANA registered iCalendar profile version identifier>
     ;Minimum iCalendar version used to create the iCalendar object

     maxver     = <A IANA registered iCalendar profile version identifier>
     ;Maximum iCalendar version used to create the iCalendar object

   The following is an example of this property:

     VERSION:2.0

   The data type for this property is TEXT.

5.6

4.6     Component Properties


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

5.6.1 components, as
   specified by each component property definition.

4.6.1   Attachment


   This property is identified by the property name ATTACH. The property
   provides the capability to associate an external object with a
   calendar component. For example, a document to be reviewed at a
   scheduled event or the description of the process steps for a to-do.
   The property may MAY only be specified within event, to-do, "VEVENT", "VTODO", or journal
   "VJOURNAL" calendar components. This property may MAY be specified
   multiple times within an iCalendar object.

   The property is defined by the following notation:

     attach     = "ATTACH" ":" [ws] url CRLF

   The following are examples of this property:

     ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com




Dawson/Stenerson                   38                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


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

   The data type for this property is URL.

5.6.2

4.6.2   Attendee


   This property is identified by the property name ATTENDEE. The
   property defines an attendee within a calendar component. The
   property may MAY only be specified within the event, to-do "VEVENT", "VTODO",
   "VJOURNAL" and free/busy "VFREEBUSY" calendar components.

   The property has the property parameters TYPE, for the type of
   attendee, ROLE, for the intended role of the attendee; STATUS, for
   the status of the attendee’s participation; RSVP, for indicating
   whether the favor of a reply is requested; EXPECT, to indicate the
   expectation of the attendee’s participation by the originator;
   MEMBER, to indicate the group groups that the attendee belongs to;

Dawson/Stenerson                   33              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   DELEGATED-TO, to indicate the person people that the original request was
   delegated to; and DELEGATED-FROM, to indicated whom the request was
   delegated from.

   A recipient delegated a request MUST inherit the RSVP and EXPECT
   values from the attendee that delegated the request to them.

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

   The property data type default is CAL-ADDRESS. The property data type
   may
   MAY also be set to URL. This provides a useful mechanism to allow
   more than just the address of the attendee to be referenced. For
   example, If the property
   value may refer is a URL, then it MUST be able to be resolved to a URL. calendar
   address.

   The property is defined by the following notation:

     attendee   = "ATTENDEE" [";" [ws] paramlist]
                  [";" [ws] attparamlist] ":" [ws]
                  (cal-address / URL) CRLF
     ;Value must MUST match default or explicit data type

     attparamlist      = attparam / attparamlist ";" attparam
                        / paramlist / paramlist ";" attparam
                        / paramlist ";" attparamlist ";"
                          attparam (attparam *(";" attparam)

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

     typeparm   = "TYPE" "="
                ("INDIVIDUAL"   ; An individual
                / "GROUP"       ; A group of individuals
                / "RESOURCE"    ; A physical resource
                / "ROOM"        ; A room resource
                / "UNKNOWN")    ; Otherwise not known
     ;Default value is UNKNOWN INDIVIDUAL




Dawson/Stenerson                   39                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     roleparm   = "ROLE" "="
                ("ATTENDEE"     ; Indicates a regular attendee
                / "OWNER"       ; Indicates owner of event or to-do
                / "ORGANIZER"   ; Indicates organizer of event or to-do
                / "DELEGATE")   ; Indicates delegate to event or to-do
     ;Default is ATTENDEE

     statusparm = "STATUS" "="
                ("NEEDS-ACTION" ; Indicates event or to-do needs action
                / "ACCEPTED"    ; Indicates event or to-do accepted
                / "DECLINED"    ; Indicates event or to-do not accepted
                / "TENTATIVE"   ; Indicates event or to-do tentatively
                ; accepted. Status may MAY change in the future.
                / "COMPLETED"   ; Indicates to-do was completed.
                ; COMPLETED property has date/time completed.
                / "IN-PROCESS"  ;Indicates to-do is in the process of
                ; being completed.
                / "DELEGATED"   ; Indicateds event or to-do delegated
                ; to another ATTENDEE
                / "CANCELED") "CANCELLED")  ; Indicates event or to-do canceled cancelled for
                                ; ATTENDEE
     ;Default is NEEDS-ACTION

Dawson/Stenerson                   34              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     rsvpparm   = "RSVP" "="
                  ("TRUE"               ; Indicates response requested
                / "FALSE")              ; Indicates no response needed
     ;Default is FALSE

     expectparm = "EXPECT" "="
                ("FYI"          ; Indicates request is for your info
                / "REQUIRE"     ; Indicates presence is required
                / "REQUEST")    ; Indicates presence is requested
     ;Default is FYI

     memberparm = "MEMBER" "=" cal-address *("," cal-address)
     ; Indicates a group or mailing list

     deletoparm = "DELEGATED-TO" "=" cal-address *("," cal-address)
     ; Indicates who request delegated to

     delefromparm = "DELEGATED-FROM" "=" cal-address *("," cal-address)
     ;Indicates who request delegated from

   The following are examples of this property’s use for a to-do:

     ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:jsmith@host1.com
     ATTENDEE;MEMBER=DEV-GROUP:joecool@host2.com
     ATTENDEE;MEMBER=DEV-GROUP@host2.com:joecool@host2.com
     ATTENDEE;DELEGATED-FROM=immud@host3.com:ildoit@host1.com

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

     ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:John

     ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith <jsmith@host1.com>
     ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:Henry Cabot


Dawson/Stenerson                   40                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


      <hcabot@host2.com>
     ATTENDEE;ROLE=DELEGATE;STATUS=CONFIRMED:Jane
     ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED: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:

     ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;VALUE=URL:

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

   The following is an example of this property with "delegatee"
   and"delegator" information for an event:

     ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith <jsmith@host1.com>
     ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM=
      iamboss@host2.com:Henry Cabot<hcabot@host2.com>
     ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO=
      hcabot@host2.com=iamboss(The Big Cheese)@host2.com
     ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe <jdoe@host1.com>

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



Dawson/Stenerson                   35              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

5.6.3

4.6.3   Categories


   This property is identified by the property name CATEGORIES. This
   property defines the categories for a calendar component. The
   property may MAY be specified within the event, to-do "VEVENT", "VTODO" or journal "VJOURNAL"
   calendar component with an arbitrary text value. The In the "VALARM"
   calendar component the property may also MUST be specified within the alarm property with a value of to declare the
   alarm category. More than one category may MAY be specified as a list of
   categories separated by the COMMA character (ASCII decimal 44).

   The properties is defined by the following notation:

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

     catvalue   = cat1value *["," [ws] cat1value]
                / cat2value *["," [ws] cat2value]

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

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



Dawson/Stenerson                   41                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The following are examples of this property in an event, to-do in a "VEVENT", "VTODO" or
   journal
   "VJOURNAL" calendar component:

     CATEGORIES:APPOINTMENT,EDUCATION

     CATEGORIES:MEETING

   The following are examples of this property in an alarm a "VALARM" calendar
   component:

     CATEGORIES:AUDIO,DISPLAY

     CATEGORIES:PROCEDURE

   The data type for this property is TEXT.

5.6.4

4.6.4   Classification


   This property is identified by the property name CLASS. This property
   defines the access classification for a calendar component. The
   property may MAY only be specified in an event, to-do a "VEVENT", "VTODO" or journal "VJOURNAL"
   calendar component. The property may MAY only be specified once.

   An access classification is only one component of the general
   security system within a calendar application. It provides a method
   of capturing the scope of the access the calendar owner intends for
   information within an individual calendar entry. The access

Dawson/Stenerson                   36              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   classification of an individual iCalendar component is useful when
   measured along with the other security components of a calendar
   system (e.g., calendar user authentication, authorization, access
   rights, access role, etc.). Hence, the semantics of the individual
   access classifications can not be completely defined by this specification memo
   alone. Additionally, due to the "blind" nature of most exchange
   processes using this
   specification, memo, these access classifications can not serve
   as an enforcement statement for a system receiving an iCalendar
   object . Rather, they provide a method for capturing the intention of
   the calendar owner for the access to the calendar component. . The
   [ICMS] provides a broader description of the security system within a
   calendar application.

   The property is defined by the following notation:

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

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

   The following is an example of this property:

     CLASS:PUBLIC

   The data type for this property is TEXT.

5.6.5



Dawson/Stenerson                   42                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


4.6.5   Comment


   This property is identified by the property name COMMENT. This
   property specifies non-processing information intended to provide a
   comment to the calendar user. The property may MAY be specified in any of
   the calendar components. The property may MAY be specified multiple
   times.

   The property is defined by the following notation:

     comment    = "COMMENT" ":" [ws] text CRLF

   The following is an example of this property:

     COMMENT:The meeting really needs to include both ourselves
       and the customer.  We can’t hold this  meeting without them. them
       As a matter of fact, fact\, the venue for the meeting ought to be at
       their site. - - John

   The data type for this property is TEXT.

5.6.6

4.6.6   Contact


   This property is defined by the property name CONTACT. The property
   is used to represent contact information or alternately a reference
   to contact information associated with the calendar component. The
   property MAY only be specified in the "VEVENT", "VTODO" and
   "VJOURNAL" calendar components. The property value consists of
   textual contact information. Alternately, the value type for the
   property can be reset such that the property references the URL to
   the contact information.

   The property is defined by the following notation:

     contact    = "CONTACT" [";" [ws] paramlist] ":" [ws]
                  text / url CRLF

   The following is an example of this property referencing textual
   contact information:

     CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234

   The following is an example of this property referencing a LDAP URL
   to a directory entry containing the contact information:

   CONTACT;VALUE=URL:"ldap://host.com:6666/o=3DABC%20Industries,
     c=3DUS??(cn=3DBJim%20Dolittle)"

   The following is an example of this property referencing a MIME body
   part containing the contact information, such as a vCard embedded in
   a [MIME-DIR] content-type:

     CONTACT;VALUE=URL:<part3.msg970930T083000SILVER@host.com>



Dawson/Stenerson                   43                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The default data type for this property is TEXT. The data type MAY be
   reset to URL in order to specify a reference to the contact
   information.

4.6.7   Date/Time Completed


   This property is identified by the property name COMPLETED. This
   property defines the date and time that a to-do was actually
   completed. The property may MAY be specified once in a to-do "VTODO" component.
   The date and time is a an UTC value.

   The property is defined by the following notation:

     completed  = "COMPLETED" ":" [ws] date-time CRLF

Dawson/Stenerson                   37              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The following is an example of this property:

     COMPLETED:19960401T235959Z

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

   The data type for this property is DATE-TIME.

5.6.7

4.6.8   Date/Time Created


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

   The property is defined by the following notation:

     created    = "CREATED" ":" [ws] date-time CRLF

   The following is an example of this property:

     CREATED:19960329T133000Z

   The data type for this property is DATE-TIME.

5.6.8

4.6.9   Date/Time Due


   This property is identified by the property name DUE. This property
   defines the date and time that a to-do is expected to be completed.
   The value must be later in time than the value for the DTSTART
   property. completed.
   The time can either be in local time, local time with UTC offset or
   UTC time. The property must MAY only be specified in a to-do "VTODO" calendar component, but may
   component and only be specified once. The DUE value
   must MUST be a date/time after the
   DTSTART value. value, if specified.

   The property is defined by the following notation:

     due        = "DUE" ":" (date-time / duration) [ws] date-time CRLF
     ;Value data type must match the value

   The following is an example of this property:



Dawson/Stenerson                   44                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DUE:19960401T235959Z

   The default data type for this property is DATE-TIME. The data type
   may be reset to DURATION.

5.6.9

4.6.10  Date/Time End


   This property is identified by the property name DTEND. This property
   may
   MAY be specified within the event, free/busy, "VEVENT", "VFREEBUSY", and time zone "VTIMEZONE"
   calendar components.

   Within the event "VEVENT" calendar component, this property defines the end
   date and time for the event. The property is required REQUIRED in event "VEVENT"
   calendar components. The time can either be in local time, local time

Dawson/Stenerson                   38              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   with UTC offset or UTC time. The local time is only to be used to
   specify date and time values that do not need to be fixed. A
   recipient must MUST assume their own time zone for data and time values
   that do not include time zone information. Events may have an end
   date/time but no start date/time. In that case, the event does not
   take up any time. The value must MUST be later in
   time than the value of the DTSTART "DTSTART" property.

   Within the free/busy "VFREEBUSY" calendar component, this property defines the
   end date and time for the free or busy time information. The time
   must
   MUST be specified in local time with UTC offset or UTC time. The
   value must MUST be later in time than the value of the DTSTART "DTSTART" property.

   The property is defined by the following notation:

     dtend      = "DTEND" ":" [ws] date-time CRLF

   The following is an example of this property:

     DTEND:19960401T235959Z

   The data type for this property is DATE-TIME.

5.6.10

4.6.11  Date/Time Stamp


   This property is identified by the property name DTSTAMP. This
   property specifies an UTC date/time stamp. The property indicates the
   date/time that the iCalendar object instance was created. This
   property SHOULD MUST be included in every iCalendar object "VEVENT", "VTODO", "VJOURNAL" and
   "VFREEBUSY" calendar components to permit the recipient to know when
   the iCalendar object was created.

   This property is also useful to protocols such as [IMIP] that have
   inherent latency issues with the delivery of content. This property
   will assist in the proper sequencing of messages containing iCalendar
   objects.

   This property is different than the CREATED "CREATED" and LAST-MODIFIED "LAST-MODIFIED"
   properties. These two properties are used to specify when the
   calendar service information was created and last modified. This is
   different than when the iCalendar object representation of the
   calendar service information was created or last modified.



Dawson/Stenerson                   45                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The property is defined by the following notation:

     dtstamp    = "DTSTAMP" ":" [ws] date-time CRLF

   The value type for this property is DATE-TIME. The value must MUST be a
   UTC date/time value.

5.6.11

4.6.12  Date/Time Start


   This property is identified by the property name DTSTART. This
   property may MAY be specified within the event, free/busy, "VEVENT", "VFREEBUSY", and time zone
   "VTIMEZONE" calendar components.

   Within the event "VEVENT" calendar component, this property defines the
   start date and time for the event. The property is required REQUIRED in event
   "VEVENT" calendar components. The time can either be in local time,
   local time with UTC offset or UTC time. The local time is only to be
   used to specify date and time values that do not need to be fixed. A
   recipient must MUST assume their own time zone for data and time values

Dawson/Stenerson                   39              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   that do not include time zone information. Events may MAY have a start
   date/time but no end date/time. In that case, the event does not take
   up any time.

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

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

   The property is defined by the following notation:

     dtstart    = "DTSTART" [";" [ws] paramlist] ":" [ws] (date-time /
                  date) CRLF
     ;Date data type only permitted on Journal calendar component.

   The following is an example of this property:

     DTSTART:19960401T235959-0600

   The default data type for this property is DATE-TIME. For Journal
   calendar components, the The data type may
   MAY be overriden overridden to be DATE.

5.6.12

4.6.13  Daylight


   This property is identified by the property name DAYLIGHT. This
   property may MAY only be specified in a Time Zone Calendar Component. "VTIMEZONE" calendar component.
   This property specifies whether Daylight Saving Time (i.e., value is
   TRUE) or Standard Time (i.e., value is FALSE) is in effect for the
   time zone. The default value is FALSE or Standard Time.

   The property is defined by the following notation:



Dawson/Stenerson                   46                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


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

   The following is an example of this property:

     DAYLIGHT:TRUE              ;Specifies DST in effect in time zone

   The data type for this property is BOOLEAN.

5.6.13

4.6.14  Description


   This property is identified by the property name DESCRIPTION. This
   property provides a more complete description of the calendar
   component, than that provided by the SUMMARY "SUMMARY" property. The property
   must
   MAY be specified in the event, to-do "VEVENT", "VTODO" and journal "VJOURNAL" calendar
   components. The property may MAY be specified multiple times only within
   a journal "VJOURNAL" calendar component.

   The property is defined by the following notation:



Dawson/Stenerson                   40              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     Description        = "DESCRIPTION" [";" [ws] paramlist] ":" [ws]
                          text CRLF

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

     DESCRIPTION;ENCODING=Q: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.

     DESCRIPTION:Meeting to provide technical review for "Phoenix"
       design.\n Happy Face Conference Room. Phoenix design team
       MUST attend this meeting.\n RSVP to team leader.

   The following is an example of the property with folding of long
   lines:

     DESCRIPTION:Last draft of the new novel is to be completed
       for the editor’s proof today.

   The data type for this property is TEXT.

5.6.14

4.6.15  Duration


   This property is identified by the property name DURATION. The
   property specifies a duration of time. The property may MAY be specified
   in an event a "VEVENT" calendar component in order to specify a duration of
   the event, instead of an explicit end date/time. The property may MAY be
   specified in a free/busy "VTODO" calendar component in order to specify a
   duration for the to-do. The property MAY be specified in a
   "VFREEBUSY" calendar component in order to specify the amount of free
   time being requested. The property may MAY be specified in an alarm "VALARM"
   calendar component in order to specify the period between repeating
   alarms.

   The property is defined by the following notation:




Dawson/Stenerson                   47                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     duration   = "DURATION" ":" [ws] duration CRLF

   The following is an example of this property that specifies an
   interval of time of 1 hour and zero minutes and zero seconds:

     DURATION:PT1H0M0S

   The following is an example of this property that specifies an
   interval of time of 15 minutes.

     DURATION:PT15M

   The data type for this property is DURATION.

5.6.15

4.6.16  Exception Date/Times


   This property is identified by the property name EXDATE. This
   property defines the list of date/time exceptions for a recurring
   event or to-do component. The times can either be in local time,
   local time with UTC offset or UTC time.

   The property is defined by the following notation:



Dawson/Stenerson                   41              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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

   The following is an example of this property:

     EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z

   The data type for this property is DATE-TIME.

5.6.16  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 event or to-do. This property may only be specified in the
   event and to-do calendar components.

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

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

   The following are examples of this property. Except every other week,
   on Tuesday and Thursday for 4 occurrences:

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

   Except daily for 10 occurrences:

     EXRULE:COUNT=10;FREQ=DAILY

   Except yearly in June and July for 8 occurrences:

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

   The data type for this property is TEXT.

5.6.17  Free/Busy Time


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

   The date and time is "VJOURNAL" calendar component. The times can
   either be in local time, local time with UTC offset or a UTC
   value. time.

   The FREEBUSY property may include exception dates, if specified, is used in computing the TYPE property parameter to
   specify
   recurrence set. The recurrence set is the information defines complete set of recurrence
   instances for a free or busy time interval. calendar component. The
   property may also include recurrence set is generated
   by considering the STATUS initial "DTSTART" property parameter to specify along with the type of busy time. The STATUS parameter may be utilized by "RRULE",
   "RDATE", "EXDATE" and "EXRULE" properties contained within the
   application reading
   iCalendar object. The "DTSTART" property defines the busy time information first instance
   in order to provide a
   richer view the recurrence set. Multiple instances of the information. "RRULE" and "EXRULE"
   properties MAY also be specified to define more sophisticated
   recurrence sets. The property final recurrence set is defined generated by gathering
   all of the following notation:


Dawson/Stenerson                   42              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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

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

     fbparam    = fbtype / fbstatus

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

     fbstatus   = "STATUS" "="
                  "BUSY"        ;Represents busy time interval
                / "OUT"         ;Represents out-of-office, non-working
                                ;hours, or other unavailable interval
                / "PRIVATE"     ;Represents private unavailable time 
                / "CONFIDENTIAL" ;Represents confidential unavailable
                                ;time
     ;Default is BUSY

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

   The following are some examples start date-times generated by any of this property:

     FREEBUSY;STATUS=OUT:19970308T160000Z/PT8H30M

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

   FREEBUSY properties the specified "RRULE"
   and "RDATE" properties, and excluding any start date and times which
   fall within the Free/Busy Calendar Component should be
   sorted in ascending order, based on union of start date and times generated by any
   specified "EXRULE" and "EXDATE" properties. This implies that start time
   date and then end time,
   with times within exclusion related properties (i.e., "EXDATE"
   and "EXRULE") take precedence over those specified by inclusion
   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
   generated by the earliest periods first. "RRULE" and "RDATE" properties, only one recurrence
   is considered. Duplicate instances are ignored.

   The FREEBUSY property may specify more than one value, separated is defined by the COMMA character (ASCII decimal 44). In such cases, the FREEBUSY
   property values should all be of following notation:

     exdate     = "EXDATE" [";" [ws] paramlist] ":" [ws] [date-time /
                  date] *("," [ws] date-time/date) CRLF
     ;Values MUST match the same STATUS (e.g., all values specified value type.

   The following is an example of
   a particular STATUS listed together in a single property). this property:

     EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z

   The data type for this property is PERIOD.

5.6.18  Geographic Position DATE-TIME. The data type MAY be
   reset to DATE.




Dawson/Stenerson                   48                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


4.6.17  Exception Rule


   This property is identified by the property name GEO. EXRULE. This
   property
   specifies information related to the global position defines a rule or repeating pattern for an event exception to a
   recurrence set. This property MAY only be specified in the "VEVENT",
   "VTODO" or
   to-do "VJOURNAL" calendar components.

   The exception rule, if specified, is used in computing the recurrence
   set. The recurrence set is the complete set of recurrence instances
   for a calendar component. The recurrence set is generated by
   considering the initial "DTSTART" property value specifies latitude along with the "RRULE",
   "RDATE", "EXDATE" and
   longitude, in that order (i.e., "LAT LON" ordering). "EXRULE" properties contained within the
   iCalendar object. The longitude
   represents "DTSTART" defines the location east first instance in the
   recurrence set. Multiple instances of the "RRULE" and west "EXRULE"
   properties MAY also be specified to define more sophisticated
   recurrence sets. The final recurrence set is generated by gathering
   all of the prime meridian as a
   positive or negative real number, respectively. The latitude
   represents start date-times generated by any of the location north specified "RRULE"
   and south of "RDATE" properties, and excluding any start date and times which
   fall within the equator as a positive
   or negative real number, respectively. The longitude union of start date and latitude
   values must be times generated by any
   specified as decimal degrees "EXRULE" and should be specified
   to six decimal places. "EXDATE" properties. This will allow for granularity implies that start
   date and times within a meter
   of exclusion related properties (i.e., "EXDATE"
   and "EXRULE") take precedence over those specified by inclusion
   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
   generated by the geographical position. The simple formula for converting
   degrees-minutes-seconds into decimal degrees is:

     decimal = degrees + minutes/60 + seconds/3600.


Dawson/Stenerson                   43              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997 "RRULE" and "RDATE" properties, only one recurrence
   is considered. Duplicate instances are ignored.

   The property is defined by the following notation:

     geo

     exrule     = "GEO" "EXRULE" [";" [ws] paramlist] ":" geovalue [ws] recur CRLF

     geovalue   = float ";" float
     ;Latitude and Longitude components

   The following is an example are examples of this property:

     GEO:37.386013;-122.082932 property. Except every other week,
   on Tuesday and Thursday for 4 occurrences:

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

   Except daily for 10 occurrences:

     EXRULE:FREQ=DAILY;COUNT=10

   Except yearly in June and July for 8 occurrences:

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

   The default data type for this property is FLOAT.

5.6.19  Last Modified RECUR.

4.6.18  Free/Busy Time


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





Dawson/Stenerson                   49                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The
   property specifies the date and time that is either local time with UTC offset or a UTC
   value.

   The "FREEBUSY" property MAY include the "TYPE" property parameter to
   specify whether the calendar information
   was last revised. defines a free or busy time interval.
   The default "TYPE" property parameter value may is BUSY. The property MAY
   also include multiple "date-time"
   values in order to capture the sequence of modifications made "STATUS" property parameter to provide added
   information about the
   calendar information. This property may busy time. For example, if the busy time is
   associated with a time interval that would be specified unavailable for
   scheduling - - in the event,
   to-do, journal any case - - or free/busy calendar components. The data and busy time
   must be a UTC value. that has been tentatively
   scheduled. The default "STATUS" property parameter value is BUSY. The
   property is defined by the following notation:

     last-mod

     freebusy   = "LAST-MODIFIED" "FREEBUSY" [";" [ws] paramlist] [";" [ws] fbparmlist]
                  ":" date-time ["," date-time] [ws] fbvalue CRLF

     fbparmlist = fbparam *(";" [ws] fbparam)

     fbparam    = fbtype / fbstatus

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

     fbstatus   = "STATUS" "="
                  "BUSY"        ;Represents busy time interval.
                / "UNAVAILABLE" ;Represents busy, but unavailable
                                ;interval for cheduling; such as
                                ;out-of-office or non-working hours.
                / "TENTATIVE"   ;Represents busy, but tentatively
                                ;scheduled interval.
     ;Default is BUSY

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

   The following is are some examples of this property:

     LAST-MODIFIED:19960817T133000Z

     LAST-MODIFIED:19970104T083000-0500,19970403T090000-0500,
      19970901T133000-0400 this property:

     FREEBUSY;STATUS=UNAVAILABLE:19970308T160000Z/PT8H30M

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

   "FREEBUSY" properties within the "VFREEBUSY" calendar component
   should be sorted in ascending order, based on start time and then end
   time, with the earliest periods first.

   The "FREEBUSY" property MAY specify more than one value, separated by
   the COMMA character (ASCII decimal 44). In such cases, the "FREEBUSY"
   property values should all be of the same "STATUS" property parameter
   type (e.g., all values of a particular "STATUS" listed together in a
   single property).

   The data type for this property is DATE-TIME.

5.6.20  Location PERIOD.




Dawson/Stenerson                   50                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


4.6.19  Geographic Position


   This property is identified by the property name LOCATION. The GEO. This property defines
   specifies information related to the intended location global position for the event a "VEVENT"
   or to-do "VTODO" calendar component. The property may only value specifies latitude
   and longitude, in that order (i.e., "LAT LON" ordering). 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 longitude and latitude
   values MUST be specified as decimal degrees and should be specified
   to six decimal places. This will allow for granularity within an
   event or to-do calendar component. a meter
   of the geographical position. The simple formula for converting
   degrees-minutes-seconds into decimal degrees is:

     decimal = degrees + minutes/60 + seconds/3600.

   The property is defined by the following notation:

     location

     geo        = "LOCATION [";" paramlist] "GEO" ":" locavalue [ws] geovalue CRLF

     locavalue

     geovalue   = text / url    ;The value must be the same type as the
                                ;default or explicit data type.

   The following are some examples of this property:

     LOCATION:Conference Room - F123, Bldg. 002


Dawson/Stenerson                   44              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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

   The default data type for this property is TEXT. The data type may be
   reset to URL. In the case of the data type being URL, the property
   value may reference a vCard object. This provides a useful mechanism
   to specify a location in terms float ";" [ws] float
     ;Latitude and Longitude components

   The following is an example of its electronic business card.

5.6.21  Priority this property:

     GEO:37.386013;-122.082932

   The default data type for this property is FLOAT.

4.6.20  Last Modified


   This property is identified by the property name PRIORITY. LAST-MODIFIED. The
   property defines specifies the priority for event or to-do. The date and time that the calendar information
   was last revised. This property may
   only MAY be specified within an event in the "VEVENT",
   "VTODO", "VJOURNAL" or to-do "VFREEBUSY" calendar component. components. The
   value is an integer. A value of zero (ASCII decimal 48) specifies an
   undefined priority. A value of one (ASCII decimal 49) is the highest
   priority. A value of two (ASCII decimal 50) is the second highest
   priority. Subsequent numbers specify data and
   time MUST be a decreasing ordinal priority. UTC value.

   The property is specified defined by the following notation:

     priority

     last-mod   = "PRIORITY" "LAST-MODIFIED" ":" integer [ws] date-time CRLF
     ;Default is zero

   The following is an example are examples of this property:

     PRIORITY:2

     LAST-MODIFIED:19960817T133000Z

   The data type for this property is INTEGER.

5.6.22  Recurrence Date/Times DATE-TIME.

4.6.21  Location


   This property is identified by the property name RDATE. This LOCATION. The
   property defines the list of date/times intended location for a recurring event, to-do the "VEVENT" or time
   zone "VTODO"




Dawson/Stenerson                   51                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   calendar component. This property may appear along with the
   RRULE property to define an aggregate set of repeating occurrences.
   When they both appear in an iCalendar object, the recurring events
   are defined by the union of occurrences defined by both the RDATE and
   RRULE. The times can either be in local time, local time with UTC
   offset or UTC based time. If local time is used, the TIMEZONE
   component must be included in the iCalendar object, otherwise the
   local time value will property MAY only be interpreted relative to the time zone of the
   recipient. The period values for RDATE are specified using a specific
   start and within a specific end basic format (period-explicit)
   "VEVENT" or the period
   with a specific start and a specific duration basic format (period-
   start). "VTODO" calendar component.

   The property is defined by the following notation:

     rdate

     location   = "RDATE" "LOCATION [";" [ws] paramlist] ":" rdvalue *["," rdvalue] [ws] locavalue
                  CRLF

     rdvalue

     locavalue  = date-time text / period
     ;Value must match url    ;The value MUST be the default same type as the
                                ;default or explicit data type type.

   The following are some examples of this property:

     RDATE:19970714T083000-0400


Dawson/Stenerson                   45              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
      19960404T010000Z/PT3H

     RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
      19970526,19970704,19970901,19971014,19971128,19971129,19971225

     LOCATION:Conference Room - F123, Bldg. 002

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

   The default data type for this property is DATE-TIME. TEXT. The value may data type MAY be
   reset to DATE or PERIOD.

5.6.23  Recurrence ID URL. In the case of the data type being URL, the property
   value MAY reference a vCard object. This provides a useful mechanism
   to specify a location in terms of its electronic business card.

4.6.22  Percent Complete


   This property is identified by the property name RECURRENCE-ID. PERCENT-COMPLETE.
   This property identifies is used by an assignee or delegatee of a specific instance to-do to
   convey the percent completion of a recurring event, to-do
   or journal to the Organizer. The
   property MAY only be specified once and within a "VTODO" calendar
   component. The property value is the effective
   DTSTART an integer between zero and one
   hundred. A value of "0" indicates the recurrence instance. The time to-do has not yet been started.
   A value of day component
   for "100" indicates that the value must be either an UTC or a local time with UTC offset
   time format, unless to-do has been completed. Integer
   values in between indicate the original calendar object was expressed as percent partially complete.

   When a
   ‘   ‘floating’
             ’ calendar object; that is in local time with no timezone
   calendar component specified..

   The date/time value to-do is set assigned to multiple individuals, the time when the original recurrence
   instance would occur - - meaning that if property value
   indicates the intent is to change a
   Friday meeting to Thursday, percent complete for that portion of the date/time is still set to-do assigned
   to the
   original Friday meeting.

   Recurrence ID assignee or delegatee. For example, if a to-do is used in conjunction assigned to
   both individuals "A" and "B". A reply from "A" with a percent
   complete of "70" indicates that "A" has completed 70% of the UID property to-do
   assigned to
   identify them. A reply from "B" with a particular instance percent complete of a recurring event, "50"
   indicates "B" has completed 50% of the to-do or
   journal. assigned to them.

   The property is defined by the following notation:

     recurid

     percent = "RECURRENCE-ID" [";" rangeparm] "PERCENT-COMPLETE" ":" date-time

     rangeparm  = "RANGE" "=" ("THISANDPRIOR" / "THISANDFUTURE")

   The default value for the range parameter is the single recurrence
   instance only. [ws] integer CRLF

   The following are examples is an example of this property:

     RECURRENCE-ID:19960401T235959Z

     RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z

5.6.24  Recurrence Rule property to show 39% completion:

     PERCENT-COMPLETE:39

   The data type for this property is INTEGER.  






Dawson/Stenerson                   52                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


4.6.23  Priority


   This property is identified by the property name RRULE. This PRIORITY. The
   property defines a rule or repeating pattern the priority for a recurring events, to-dos, event or time zone definitions. to-do. The property may MAY
   only be specified in the event,
   to-do, within a "VEVENT" or time zone "VTODO" calendar components. component.
   The property value is a structured an integer. A value consisting of a list zero (ASCII decimal 48) specifies
   an undefined priority. A value of one
   or more recurrence grammar components. Each component (ASCII decimal 49) is defined by the
   highest priority. A value of two (ASCII decimal 50) is the second
   highest priority. Subsequent numbers specify a
   NAME=VALUE pair. decreasing ordinal
   priority.

   The components are separated from each other property is specified by the
   SEMICOLON character (ASCII decimal 59).


Dawson/Stenerson                   46              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997 following notation:

     priority   = "PRIORITY" ":" [ws] integer CRLF
     ;Default is zero

   The following is an example of this property:

     PRIORITY:2

   The FREQ component identifies the data type for this property is INTEGER.

4.6.24  Recurrence Date/Times


   This property is identified by the property name RDATE. This property
   defines the list of date/times for a recurrence rule. set. The property MAY
   only appear within the "VEVENT", "VTODO", "VJOURNAL" or "VTIMEZONE"
   calendar components. This
   component must be specified in property MAY appear along with the recurrence rule. Valid values
   include HOURLY, "RRULE"
   property to specify repeating events based on define an interval aggregate set of
   an hour or more; DAILY, to specify repeating events based on occurrences. When
   they both appear in an
   interval of a day or more; WEEKLY, to specify repeating iCalendar object, the recurring events based
   on an interval are
   defined by the union of a week occurrences defined by both the "RDATE" and
   "RRULE". The times can either be in local time, local time with UTC
   offset or more; MONTHLY, to specify repeating
   events UTC based on an interval of a month or more; and YEARLY, time. If local time is used, the "VTIMEZONE"
   calendar component MUST be included in the iCalendar object,
   otherwise the local time value will be interpreted relative to
   specify repeating events based on an interval the
   time zone of a year or more.

   The INTERVAL component contains a positive integer representing how
   often the RRULE repeats. recipient. The default value is "1" or every hour period values for "RDATE" property
   are specified using a
   HOURLY rule, every day for specific start and a DAILY rule, every week for specific end basic format
   (period-explicit) or the period with a WEEKLY
   rule, every month specific start and a specific
   duration basic format (period-start).

   The recurrence dates, if specified, is used in computing the
   recurrence set. The recurrence set is the complete set of recurrence
   instances for a MONTHLY rule calendar component. The recurrence set is generated
   by considering the initial "DTSTART" property along with the "RRULE",
   "RDATE", "EXDATE" and every year for a YEARLY
   rule. For a HOURLY rule, "EXRULE" properties contained within the value may
   iCalendar object. The "DTSTART" property defines the first instance
   in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
   properties MAY also be expressed as a
   duration value, specifying hours and minutes for specified to define more sophisticated
   recurrence sets. The final recurrence set is generated by gathering
   all of the repeat interval.
   For example, PT1H30M, would represent a 1 hour start date-times generated by any of the specified "RRULE"
   and 30 minute repeat
   interval.

   The UNTIL component defines a date-time value "RDATE" properties, and excluding any start date and times which bounds
   fall within the RRULE.
   If not present, union of start date and times generated by any
   specified "EXRULE" and "EXDATE" properties. This implies that start



Dawson/Stenerson                   53                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   date and times within exclusion related properties (i.e., "EXDATE"
   and "EXRULE") take precedence over those specified by inclusion
   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
   generated by the COUNT component "RRULE" and "RDATE" properties, only one recurrence
   is also not present, considered. Duplicate instances are ignored.

   The property is defined by the
   RRULE following notation:

     rdate      = "RDATE" [";" [ws] paramlist] ":" [ws] rdvalue
                  *("," [ws] rdvalue) CRLF

     rdvalue    = date-time / date / period
     ;Value MUST match the specified data type

   The following are examples of this property:

     RDATE:19970714T083000-0400

     RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
      19960404T010000Z/PT3H

     RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
      19970526,19970704,19970901,19971014,19971128,19971129,19971225

   The default data type for this property is considered to repeat forever. DATE-TIME. The COUNT component defines the number of occurrences at which data type
   MAY be reset to
   bound the RRULE. DATE or PERIOD.

4.6.25  Recurrence ID


   This component property is ignored if identified by the UNTIL property
   parameter is also present.

   The BYDAY component specifies name RECURRENCE-ID. This
   property identifies a COMMA character (ASCII decimal 44)
   separated list of days of the week; MO, indicates Monday; TU,
   indicates Tuesday; WE, indicates Wednesday; TH, indicates Thursday;
   FR, indicates Friday; SA, indicates Saturday; SU, indicates Sunday.

   Each specific instance of these values may also be preceded by a positive (+n) recurring "VEVENT",
   "VTODO" or
   negative (-n) integer. If present, this indicates "VJOURNAL" calendar component. The property value is the nth occurrence
   effective value of the specific "DTSTART" property of the recurrence instance.
   The time of day within component for the MONTHLY value MUST be either an UTC or YEARLY RRULE. For example,
   within a MONTHLY rule, +1MO (or simply 1MO) represents the first
   Monday within the month, whereas -1MO represents the last Monday of
   local time with UTC offset time format, unless the month.

   The BYMONTHDAY component specifies original calendar
   object was expressed as a COMMA character (ASCII decimal
   44) separated list of days ‘                             ‘floating’
                                       ’ calendar object; that is in
   local time with no time zone calendar component specified. If the
   value of the month. Valid values are 1 to 31 or
   -31 to -1.

   The BYYEARDAY component specifies "DTSTART" property is a COMMA character (ASCII decimal
   44) separated list of days of DATE type value, then the year. Valid values are 1 to 366 or
   -366 to -1. For example, -1 represents value
   MUST be the last day of calendar date for the year
   (December 31st). recurrence instance.

   The BYSETPOS component specifies a COMMA character (ASCII decimal 44)
   separated list of values which corresponds date/time value is set to the nth occurrence
   within time when the set of events specified by original recurrence
   instance would occur - - meaning that if the rule. Valid values are 1 intent is to
   366 or -366 change a
   Friday meeting to -1. It must only be Thursday, the date/time is still set to the
   original Friday meeting.

   The "RECURRENCE-ID" property is used in conjunction with another
   Byxxx component. For example "the last work day the "UID"
   property to identify a particular instance of a recurring event, to-
   do or journal.

   The property is defined by the month" could
   be represented as:

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

     recurid    = "RECURRENCE-ID" [";" [ws] rangeparm] [";" [ws]
                  paramlist] ":" [ws] [date-time / date]



Dawson/Stenerson                   47                   54                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997


     rangeparm  = "RANGE" "=" ("THISANDPRIOR" / "THISANDFUTURE")

   The BYWEEKNO component specifies a comma separated list of weeks of default value for the year. Valid values range parameter is the single recurrence
   instance only.

   The following are 1 to 52. examples of this property:

     RECURRENCE-ID:19960401T235959Z

     RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z

   This corresponds to weeks
   according default data type for this property is DATE-TIME. The data type
   MAY be reset to week numbering as defined in [ISO 8601]. That is, a week
   as "A seven day period within a calendar year, starting on a Monday
   and DATE.

4.6.26  Recurrence Rule


   This property is identified by its ordinal number within the year; property name RRULE. This property
   defines a rule or repeating pattern for a recurring events, to-dos,
   or time zone definitions. The property MAY be specified in the first
   "VEVENT", "VTODO", "VJOURNAL" or "VTIMEZONE" calendar week of the year components. The
   data type for this property is RECUR.

   The recurring rule, if specified, is used in computing the one that includes recurrence
   set. The recurrence set is the first Thursday complete set of that year." This property parameter is only valid recurrence instances
   for YEARLY
   rules.

   The BYMONTH component specifies a comma separated list of months of
   the year. Valid values are 1 to 12. calendar component. The WKST property parameter specifies recurrence set is generated by
   considering the day on which initial "DTSTART" property along with the workweek
   starts. Valid values are MO, TU, WE, TH, FR, SA "RRULE",
   "RDATE", "EXDATE" and SU. This is
   significant when a WEEKLY RRULE has an interval greater than 1. The
   default value is MO.

   If two different Byxxx components are specified "EXRULE" properties contained within the RRULE, the
   recurrence occurrence must meet both criteria.

   If Byxxx component values are found which are beyond
   iCalendar object. The "DTSTART" property defines the available
   scope (ie, BYMONTHDAY=-30 first instance
   in February), they are simply ignored. If a
   positive range limit is beyond the available scope, it will be
   interpreted as -1. Likewise, if a negative range limits beyond recurrence set. Multiple instances of the
   available scope, it will "RRULE" and "EXRULE"
   properties MAY also be interpreted as +1. specified to define more sophisticated
   recurrence sets. The RRULE property requires referencing final recurrence set is generated by gathering
   all of the DTSTART, DTEND or
   DURATION start date-times generated by any of the specified "RRULE"
   and "RDATE" properties, and excluding any start date and times which
   fall within the union of start date and times generated by any
   specified "EXRULE" and "EXDATE" properties. This implies that start
   date and times within exclusion related properties (i.e., "EXDATE"
   and "EXRULE") take precedence over those specified by inclusion
   properties in the iCalendar object to calculate (i.e., "RDATE" and "RRULE"). Where duplicate instances are
   generated by the Event or
   To-do instances. "RRULE" and "RDATE" properties, only one recurrence
   is considered. Duplicate instances are ignored.

   The DTSTART "DTSTART" and DTEND "DTEND" property pair or DTSTART "DTSTART" and DURATION "DURATION"
   property pair, specified within the iCalendar object defines the
   first instance of the recurrence. When used with a recurrence rule,
   the DTSTART "DTSTART" and DTEND "DTEND" properties must MUST be specified in local time and the appropriate set of
   TIMEZONE components must be included. For detail on the usage of the
   TIMEZONE component, see the Time Zone Calendar Component definition.

   Any duration associated with the iCalendar object applies to all
   members of the generated recurrence. Any modified duration for
   specific recurrences would have to be explicitly specified using the
   RDATE property.

   This property is defined by the following notation:

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

     paramlist  = param / paramlist ";" param

     rvalue     = "FREQ" = freq
                *("UNTIL" "=" enddate
                / "COUNT" "=" interval
                / "INTERVAL" "=" rinterval
                / "BYDAY" "=" bdweekdaylist
                / "BYMONTHDAY" "=" bmdaylist
                / "BYYEARDAY" "=" bydaylist
                / "BYSETPOS" "=" bsplist
                / "BYWEEKNO" "=" bwdaylist

Dawson/Stenerson                   48              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

                / "BYMONTH" "=" bmlist
                / "WKST" "=" weekday
                / "X-" word "=" word)

     freq       = "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY"

     rinterval  = interval      ; For any rvalue
                / duration      ; Only for rvalue = HOURLY

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

     digits     = 1*DIGIT

     interval   = digits

     enddate    = date          ;A UTC value

     plus       = "+"

     minus      = "-"

     ordmoday   = 1*2digits     ;1 to 31

     ordwk      = 1*2digits     ;1 to 52

     ordyrday   = 1*3digits     ;1 to 366

     daynumber  = (plus / minus) ordmoday

     weekday    = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
     ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
     ;FRIDAY, SATURDAY local time
   and SUNDAY days the appropriate set of "VTIMEZONE" calendar components MUST be
   included. For detail on the week.

     bdweekdaynum = [daynumber] weekday

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

     bmposday   = [plus] ordmoday

     bmnegday   = minus ordmoday

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

     byposday   = [plus] ordyrday

     bynegday   = minus ordyrday

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

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

     bwposday   = [plus] ordwk usage of the "VTIMEZONE" calendar
   component, see the "VTIMEZONE" calendar component definition.

   Any duration associated with the iCalendar object applies to all
   members of the generated recurrence. Any modified duration for
   specific recurrences would have to be explicitly specified using the
   "RDATE" property.



Dawson/Stenerson                   49                   55                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

     bwnegday   = minus ordwk

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

     bmposmon   = 1*2digits     ;1 to 12

     bmlist


   This property is defined by the following notation:

     rrule      = bmposmon *("," bmposmon) "RRULE" [";" [ws] paramlist] ":" [ws] recur CRLF

   Examples of this property include the following. All examples assume
   the Eastern United States time zone.

   Daily for 10 occurrences:

     RRULE:COUNT=10;FREQ=DAILY

     DTSTART:19970902T090000-0400
     RRULE:FREQ=DAILY;COUNT=10

     ==> (1997 9AM EDT)September 2-11

   Daily until 12/24/94:

     RRULE:UNTIL=19941224T000000Z;FREQ=DAILY 12/24/97:

     DTSTART:19970902T090000-0400
     RRULE:FREQ=DAILY;UNTIL=19971224T000000Z

     ==> (1997 9AM EDT)September 2-30;October 1-25
         (1997 9AM EST)October 26-31;November 1-30;December 1-24

   Every other day - forever:

     RRULE:INTERVAL=2;FREQ=DAILY

     DTSTART:19970902T090000-0400
     RRULE:FREQ=DAILY;INTERVAL=2
     ==> (1997 9AM EDT)September2,4,6,8...24,26,28,30;
          October 2,4,6...20,22,24
         (1997 9AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
          Dec 1,3,...

   Every 10 days, 5 occurrences:

     RRULE:COUNT=5;INTERVAL=10;FREQ=DAILY

     DTSTART:19970902T090000-0400
     RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5

     ==> (1997 9AM EDT)September 2,12,22;October 2,12

   Everyday in January, for 3 years:

     DTSTART:19980101T090000-0400
     RRULE:FREQ=YEARLY;UNTIL:20000131T090000-0400;BYMONTH=1;BYDAY=SU,
      MO,TU,WE,TH,FR,SA
     or
     RRULE:FREQ=DAILY;UNTIL:20000131T090000-0400;BYMONTH=1

     ==> (1998 9AM EDT)January 1-31
         (1999 9AM EDT)January 1-31
         (2000 9AM EDT)January 1-31

   Weekly for 10 occurrences

     RRULE:COUNT=10;FREQ=WEEKLY

     DTSTART:19970902T090000-0400
     RRULE:FREQ=WEEKLY;COUNT=10


Dawson/Stenerson                   56                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997



     ==> (1997 9AM EDT)September 2,9,16,23,30;October 7,14,21
         (1997 9AM EST)October 28;November 4

   Weekly until 12/24/94

     RRULE:UNTIL=19941224T000000Z;FREQ=WEEKLY

     DTSTART:19970902T090000-0400
     RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

     ==> (1997 9AM EDT)September 2,9,16,23,30;October 7,14,21
         (1997 9AM EST)October 28;November 4,11,18,25;
                       December 2,9,16,23,24

   Every other week - forever:

     RRULE:INTERVAL=2;WKST=SU;FREQ=WEEKLY

     DTSTART:19970902T090000-0400
     RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU

     ==> (1997 9AM EDT)September 2,16,30;October 14
         (1997 9AM EST)October 28;November 11,25;December 9,23
         (1998 9AM EST)January 6,20;February
     ...


   Weekly on Tuesday and Thursday for 5 weeks:

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

     DTSTART:19970902T090000-0400
     RRULE:FREQ=WEEKLY;UNTIL=19971007T000000-0400;WKST=SU;BYDAY=TU,TH
     or
     RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH

     ==> (1997 9AM EDT)September 2,4,9,11,16,18,23,25,30;October 2

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

     RRULE:INTERVAL=2;WKST=SU;BYDAY=MO,WE,FR;=UNTIL=19941224T000000Z;
      FREQ=WEEKLY 12/24/97, but
   starting on Tuesday, 9/2/97:

     DTSTART:19970902T090000-0400
     RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000-0400;WKST=SU;
      BYDAY=MO,WE,FR
     ==> (1997 9AM EDT)September 2,3,5,15,17,19,29;October 1,3,13,15,17
         (1997 9AM EST)October 27,29,31;November 10,12,14,24,26,28;
                       December 8,10,12,22,24

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

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

     DTSTART:19970902T090000-0400
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH

     ==> (1997 9AM EDT)September 2,4,16,18,30;October 2,14,16

   Monthly on the 1st Friday for ten occurrences:

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

   Monthly on the 1st Friday until 12/24/94:

     DTSTART:19970905T090000-0400
     RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR


Dawson/Stenerson                   50                   57                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997

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



     ==> (1997 9AM EDT)September 5;October 3
         (1997 9AM EST)November 7;Dec 5
         (1998 9AM EST)January 2;February 6;March 6;April 3
         (1998 9AM EDT)MAY 1;June 5

   Monthly on the 1st Friday until 12/24/94:

     DTSTART:19970905T090000-0400
     RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR

     ==> (1997 9AM EDT)September 5;October 3
         (1997 9AM EST)November 7;December 5

   Every other month on the 1st and last Sunday of the month for
   10occurrences:

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

     DTSTART:19970907T090000-0400
     RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU

     ==> (1997 9AM EDT)September 7,28
         (1997 9AM EST)November 2,30
         (1998 9AM EST)January 4,25;March 1,29
         (1998 9AM EDT)MAY 3,31

   Monthly on the second to last Monday of the month for 6 months:

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

     DTSTART:19970922T090000-0400
     RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO

     ==> (1997 9AM EDT)September 22;October 20
         (1997 9AM EST)November 17;December 22
         (1998 9AM EST)January 19;February 16

   Monthly on the third to the last day of the month, forever:

     RRULE:BYMONTHDAY=-3;FREQ=MONTHLY

     DTSTART:19970928T090000-0400
     RRULE:FREQ=MONTHLY;BYMONTHDAY=-3

     ==> (1997 9AM EDT)September 28
         (1997 9AM EST)October 29;November 28;December 29
         (1998 9AM EDT)January 29;February 26
     ...

   Monthly on the 2nd and 15th of the month for 10 occurrences:

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

     DTSTART:19970902T090000-0400
     RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15

     ==> (1997 9AM EDT)September 2,15;October 2,15
         (1997 9AM EST)November 2,15;December 2,15
         (1998 9AM EST)January 2,15

   Monthly on the first and last day of the month for 10 occurrences:

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


Dawson/Stenerson                   58                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DTSTART:19970930T090000-0400
     RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1

     ==> (1997 9AM EDT)September 30;October 1
         (1997 9AM EST)October 31;November 1,30;December 1,31
         (1998 9AM EST)January 1,31;February 1

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

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

   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:

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

     DTSTART:19970910T090000-0400
     RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
      15

     ==> (1997 9AM EDT)September 10,11,12,13,14,15
         (1999 9AM EST)March 10,11,12,13

   Every Tuesday, every other month:

     DTSTART:19970902T090000-0400
     RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU

     ==> (1997 9AM EDT)September 2,9,16,23,30
         (1997 9AM EST)November 4,11,18,25
         (1998 9AM EST)January 6,13,20,27;March 3,10,17,24,31
     ...

   Yearly in June and July for 10 occurrences:

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

     DTSTART:19970610T090000-0400
     RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7

     ==> (1997 9AM EDT)June 10;July 10
         (1998 9AM EDT)June 10;July 10
         (1999 9AM EDT)June 10;July 10
         (2000 9AM EDT)June 10;July 10
         (2001 9AM EDT)June 10;July 10
     Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
     are specified, the day is gotten from DTSTART

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

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

     DTSTART:19970310T090000-0400
     RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3

     ==> (1997 9AM EST)March 10
         (1999 9AM EST)January 10;February 10;March 10
         (2001 9AM EST)January 10;February 10;March 10
         (2003 9AM EST)January 10;February 10;March 10

   Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:

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

     DTSTART:19970101T090000-0400
     RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200


Dawson/Stenerson                   59                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997



     ==> (1997 9AM EST)January 1
         (1997 9AM EDT)April 10;July 19
         (2000 9AM EST)January 1
         (2000 9AM EDT)April 9;July 18
         (2003 9AM EST)January 1
         (2003 9AM EDT)April 10;July 19
         (2006 9AM EST)January 1

   Every 20th Monday of the year, forever:

     RRULE:BYDAY=20MO;FREQ=YEARLY

     DTSTART:19970519T090000-0400
     RRULE:FREQ=YEARLY;BYDAY=20MO

     ==> (1997 9AM EDT)MAY 19
         (1998 9AM EDT)MAY 18
         (1999 9AM EDT)MAY 17
     ...

   Monday of Week No. 20, forever:

     RRULE:BYWEEKNO=20;BYDAY=MO;FREQ=YEARLY

     DTSTART:19970512T090000-0400
     RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO

     ==> (1997 9AM EDT)MAY 12
         (1998 9AM EDT)MAY 11
         (1999 9AM EDT)MAY 17
     ...

   Every Thursday in March, forever:


Dawson/Stenerson                   51              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     RRULE:BYDAY=TH;BYMONTH=3;FREQ=YEARLY

     DTSTART:19970313T090000-0400
     RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH

     ==> (1997 9AM EST)March 13,20,27
         (1998 9AM EST)March 5,12,19,26
         (1999 9AM EST)March 4,11,18,25
     ...

   Every Thursday, but only in the summer, during summer months, forever:

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

     DTSTART:19970605T090000-0400
     RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8

     ==> (1997 9AM EDT)June 5,12,19,26;July 3,10,17,24,31;
                       August 7,14,21,28
         (1998 9AM EDT)June 4,11,18,25;July 2,9,16,23,30;
                       August 6,13,20,27
         (1999 9AM EDT)June 3,10,17,24;July 1,8,15,22,29;
                       August 5,12,19,26
     ...

   Every Friday the 13th, forever:

     RRULE:BYDAY=FR;BYMONTHDAY=13;FREQ=MONTHLY



Dawson/Stenerson                   60                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DTSTART:19970902T090000-0400
     EXDATE:19970902T090000-0400
     RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

     ==> (1998 9AM EST)February 13;March 13;November 13
         (1999 9AM EDT)August 13
         (2000 9AM EDT)October 13
     ...

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

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

     DTSTART:19970913T090000-0400
     RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13

     ==> (1997 9AM EDT)September 13;October 11
         (1997 9AM EST)November 8;December 13
         (1998 9AM EST)January 10;February 7;March 7
         (1998 9AM EDT)April 11;MAY 9;June 13...
     ...

   Every four years, the first Tuesday after a Monday in November,
   forever (U.S. Presidential Election day):

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

     DTSTART:19961105T090000-0400
     RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
      5,6,7,8

     ==> (1996 9AM EST)November 5
         (2000 9AM EST)November 7
         (2004 9AM EST)November 2
     ...

   The 3rd instance into the month of any one of Tuesday, Wednesday or
   Thursday, for the next 3 months:

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

     DTSTART:19970904T090000-0400
     RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3

     ==> (1997 9AM EDT)September 4;October 7
         (1997 9AM EST)November 5

   The 2nd to last weekday of the month"

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

   The data type month:

     DTSTART:19970929T090000-0400
     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2

     ==> (1997 9AM EDT)September 29
         (1997 9AM EST)October 30;November 27;December 30
         (1998 9AM EST)January 29;February 26;March 30
     ...

   Every 3 hours from 9AM to 5PM on a specific day:



Dawson/Stenerson                   61                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DTSTART:19970902T090000-0400
     RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000-0400

     ==> (September 2, 1997 EDT)09:00,12:00,15:00

   Every 15 minutes for this property is TEXT.

5.6.25 6 occurrences:

     DTSTART:19970902T090000-0400
     RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6

     ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15

   Every hour and a half for 4 occurrences:

     DTSTART:19970902T090000-0400
     RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4

     ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30

   Every 20 minutes from 9AM to 4:40PM every day:

     DTSTART:19970902T090000-0400
     RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
     or
     RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16

     ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
                                ... 16:00,16:20,16:40
         (September 3 1997 EDT)9:00,9:20,9:40,10:00,10:20,
                               ...16:00,16:20,16:40
     ...

   An example where the days generated makes a difference because of
   WKST:

     DTSTART:19970805T090000-0400
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO

     ==> (1997 EDT)Aug 5,10,19,24

     changing only WKST from MO to SU, yields different reults...

     DTSTART:19970805T090000-0400
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
     ==> (1997 EDT)August 5,17,19,31

4.6.27  Related To


   This property is identified by the property name RELATED-TO. The
   property is used to represent relationships or references between one
   calendar component and another. The property may MAY only be specified in
   the event, to-do and journal "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
   The property value consists of the persistent, globally unique



Dawson/Stenerson                   62                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   identifier of another
   MIME calendar component. This value would be
   represented in a MIME calendar component by the UID "UID" property. The
   property value always points to another calendar component that has a
   "parent" relationship to the referencing object.

   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 MAY
   impact the related calendar component. For example, if a group event
   changes its start or end date or time, then the related, dependent
   events will need to have their start and end dates changed in a
   corresponding way. This property is intended only to provide
   information on the relationship of calendar components. It is up to
   the target calendar system to maintain any property implications of
   this relationship.



Dawson/Stenerson                   52              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The property is defined by the following notation:

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

     relvalue   = text

   The following is an example of this property:

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

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

     RELATED-TO:<19960401-080045-4000F192713-0052@host1.com>

   The data type for this property is TEXT.

5.6.26 UID.

4.6.28  Repeat Count


   This property is identified by the property name REPEAT. This
   property defines the number of repetitions for an alarm.

   The property is defined by the following notation:

     repeatcnt  = "REPEAT" ":" [ws] integer CRLF
     ;Default is "1".

   The following is an example of this property:

     REPEAT:4

   The data type for the property is INTEGER.

5.6.27

4.6.29  Request Status


   This property is identified by the property name REQUEST-STATUS. This
   property defines the status code returned for a scheduling request.
   This property is used to return status code information related to




Dawson/Stenerson                   63                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   the processing of an associated iCalendar object. The data type for
   this property is TEXT.

   The value consists of a short return status, a longer return status
   description, and optionally the offending data. The components of the
   value are separated by the SEMICOLON character (ASCII decimal 59).

   The short return status is a PERIOD character (ASCII decimal xx)
   separated set of integers. For example, "3.1.1". The successive
   levels of integers provide for a successive level of status code
   granularity.

   The property is defined by the following notation:

     Rstatus    = "REQUEST-STATUS" ":" [ws] statcode ";" [ws]
                         statdesc [";" [ws] extdata]

     Statcode   = 3*DIGIT
     ;Numeric 1*DIGIT *("." 1*DIGIT)
     ;Hierarchical, numeric return status code

     Statdesc   = *WORD
     ;Textual status description




Dawson/Stenerson                   53              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     Extdata    = *WORD
     ;Textual exception data. For example, the offending property
     ;name and value or complete property line.

   The following are some possible examples of this property:

     REQUEST-STATUS:200;Success

     REQUEST-STATUS:301;Invalid property value;DTSTART\:96-Apr-01
     ;Note (Note: The
   BACKSLASH character escapement of the colon character separator characters in a property value.

     REQUEST-STATUS:208; Success,
   value):

     REQUEST-STATUS:2.0;Success

     REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01

     REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
      as a single event.;RRULE:INTERVAL=2;FREQ=WEEKLY

     REQUEST-STATUS:401;Event event.;RRULE\:FREQ=WEEKLY\;INTERVAL=2

     REQUEST-STATUS:4.1;Event conflict. Date/time is busy.

     REQUEST-STATUS:307;Invalid

     REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: user;ATTENDEE\:
      jsmith@host.com

   The following are valid classes for the return status code.
   Individual iCalendar profiles object methods will define specific return
   status codes for these classes.




































Dawson/Stenerson                   54              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     |==============+===============================================|
     | Short Return Status Code | Longer Return Status Description


            1xx              |
     | Status Code  |                                               |
     |==============+===============================================|
     |    1.xx      | Preliminary success. This class of status     |
     |              | of status code indicates that the request has |
     |              | request has been initially
                                    processed, processed but that |


Dawson/Stenerson                   64                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     |              | completion is pending.


            2xx                        |
     |==============+===============================================|
     |    2.xx      | Successful. This class of status code         |
     |              | indicates that the request was completed
                                    successfully.      |
     |              | successfuly. However, the exact status code my   |
     |              | MAY indicate that a fallback has been taken.


            3xx  |
     |==============+===============================================|
     |    3.xx      | Client Error. This class of status code       |
     |              | indicates that the request was not
                                    successful. successful.|
     |              | The error is the result of either a syntax or |
     |              | a semantic error in the client formatted      |
     |              | request. Request should not be retried until  |
     |              | the condition in the request is corrected.


            4xx    |
     |==============+===============================================|
     |    4.xx      | Scheduling Error. This class of status code   |
     |              | indicates that the request was not
                                    successful. The error is the
                                    result of a scheduling
                                    conflict with the
                                    information in the
                                    associated calendar.


            5xx                     Service Error. This class of
                                    status code indicates that
                                    the request was not
                                    successful. successful.|
     |              | Some sort of error occurred within the        |
     |              | calendaring and scheduling service, not       |
     |              | directly related to the request itself.




5.6.28       |
     |==============+===============================================|

4.6.30  Resources


   This property is identified by the property name RESOURCES. This
   property defines the equipment or resources needed for the event or
   to-do. The property value is an arbitrary text. The property may MAY only

Dawson/Stenerson                   55              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   be specified in the event "VEVENT" or to-do "VTODO" calendar component. More than
   one resource may MAY be specified as a list of resources separated by the
   COMMA character (ASCII decimal 44).

   The property is defined by the following notation:

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

     resvalist  = resvalue / resvalue "," resvalist

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

   The following is an example of this property:

     RESOURCES:EASEL,PROJECTOR,VCR

   The data type for this property is TEXT.

5.6.29  Response Sequence Number


   This property is identified by the property name RESPONSE-SEQUENCE.
   This property defines the revision sequence of the calendar
   component. The property may only be specified in an event, to-do,
   journal or free/busy calendar component. 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. The first response
   to an a request is created with response sequence number of "0"
   (ASCII decimal 48). If the value is non-zero, it must be specified.
   It is incremented each time another reply is sent. the
   COMMA character (ASCII decimal 44).

   The property is defined by the following notation:

     respseq

     resource   = "RESPONSE-SEQUENCE" "RESOURCES" [";" [ws] paramlist] ":" integer [ws]
                  resvalist CRLF
     ;Default is "0".

     resvalist  = resvalue / resvalue "," [ws] resvalist

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

   The following is an example of this property:

     RESPONSE-SEQUENCE:1

     RESOURCES:EASEL,PROJECTOR,VCR

   The data type for this property is INTEGER.

5.6.30 TEXT.

4.6.31  Sequence Number


   This property is identified by the property name SEQUENCE. This
   property defines the revision sequence of the calendar component used
   in a request. The property may MAY only be specified in an event, to-do,
   journal a "VEVENT",



Dawson/Stenerson                   65                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   "VTODO", "VJOURNAL" or free/busy "VFREEBUSY" calendar component. 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. The first request is
   created with a sequence number of "0" (ASCII decimal 48). It is

Dawson/Stenerson                   56              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
   incremented each time the ORGANIZER or OWNER issues a revision to the
   request. A monotonic increment to the The sequence number is caused by a
   change to MUST be monotonically incremented when
   one of the following properties by the Organizer or Owner: in a calendar component is changed:

     · DTSTART "DTSTART"
     · "DTEND"
     · DTEND "DUE"
     · "RDATE"
     · "RRULE"
     · LOCATION "EXDATE"
     · DUE "EXRULE"

   The property is defined by the following notation:

     sequence   = "SEQUENCE" ":" [ws] integer CRLF
     ;Default is "0".

   The following is an example of this property:

     SEQUENCE:1

   The data type for this property is INTEGER.

5.6.31

4.6.32  Status


   This property is identified by the property name STATUS. This
   property defines the orignator's view of the overall status for the
   calendar component. This property may MAY only be specified in the event
   and to-do
   "VEVENT", "VTODO", "VJOURNAL" calendar components. When specified in an event calendar
   component, the The property is
   used to specify the originator's view of the general consensus for
   the meeting. When event or the to-do. In addition, when specified in a group
   scheduled to-do, to-do the property is used to specify the originator's view
   of the completion status for the to-do. The property MAY also specify
   whether the event or to-do has been cancelled.

   The property is defined by the following notation:

     status     = "STATUS" [";" [ws] paramlist] ":" [ws] statvalue CRLF

     statvalue  = "NEEDS ACTION" "NEEDS-ACTION"        ;Indicates to-do needs action.
                / "COMPLETED"           ;Indicates to-do completed completed.
                / "IN-PROCESS"          ;Indicates to-do in process of
                                        ;being completed.
                / "TENTATIVE"           ;Indicates event or to-do is being
                                        ;tentatively scheduled
                                        ;tentative.
                / "CONFIRMED"           ;Indicates event or to-do is definite
                                        ;definite.




Dawson/Stenerson                   66                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


                / "CANCELLED"           ;Indicates event or to-do was canceled
                                        ;cancelled.

   The following is an example of this property:

     STATUS:TENTATIVE

   The data type for this property is TEXT.

5.6.32

4.6.33  Summary


   This property is identified by the property name SUMMARY. This
   property defines a short summary or subject for the calendar
   component. The property may only MUST be specified in the event, to-do "VEVENT", "VTODO"
   and
   alarm "VJOURNAL" calendar components. In addition, it MAY appear in the
   "VALARM" calendar component.

   The property is defined by the following notation:

Dawson/Stenerson                   57              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     summary    = "SUMMARY" [";" [ws] paramlist] ":" [ws] text CRLF

   The following is an example of this property:

     SUMMARY:Department Party

   The data type for this property is TEXT.

5.6.33

4.6.34  Time Transparency


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

   The property is specified by the following notation:

     transp     = "TRANSP" [";" [ws] paramlist] ":" [ws] transvalue CRLF

     transvalue = "BUSY"        ;Opaque/blocks on free/busy searches
                                ;Default value is BUSY
                / "OUT"         ;Opaque/blocks on free/busy searches
                / "PRIVATE"     ;Opaque/blocks on free/busy searches
                / "CONFIDENTIAL" ;Opaque/blocks "OPAQUE"      ;Blocks or opaque on free/busy searches busy time searches.
                / "TRANSPARENT" ;Transparent on free/time searches busy time searches.

     ;Default value is OPAQUE


   The following is an example of this property for an event that is
   transparent or does not block on free/busy time searches:

     TRANSP:TRANSPARENT

   The following is an example of this property for an event that is
   opaque or blocks on free/busy time searches:

     TRANSP:BUSY

     TRANSP:OPAQUE



Dawson/Stenerson                   67                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   The data type for this property is TEXT.

5.6.34

4.6.35  Time Zone Name


   This property is identified by the property name TZNAME. This
   property specifies the customary designation for a time zone
   descripiton.
   description. This property may MAY only be specified in the Time Zone
   Calendar Component. "VTIMEZONE"
   calendar component.

   This property is defined by the following notation:

     tzname     = "TZNAME" [";" [ws] paramlist] ":" [ws] text CRLF

   The following are examples of this property:

     TZNAME: EST

     TZNAME: PDT


Dawson/Stenerson                   58              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The data type for this property is TEXT.

5.6.35

4.6.36  Time Zone Offset


   This property is identified by the property name TZOFFSET. This
   property specifies the offset from UTC for a time zone. This property
   may
   MAY only be specified in a Time Zone Calendar Component. "VTIMEZONE" calendar component. A Time Zone
   Calendar Component must
   "VTIMEZONE" calendar component MUST include this property. The
   property value is a signed numeric indicating the number of hours and
   possibly minutes from UTC. Positive numbers represents time zones
   east, or ahead of UTC. Negative numbers represents time zones west
   of, or behind UTC.

   The property is defined by the following notation:

     tzoffset   = "TZOFFSET" ":" [ws] utc-offset CRLF

   The following are examples of this property:

     TZOFFSET:-0500

     TZOFFSET:+0530

   The data type for this property is UTC-OFFSET.

5.6.36

4.6.37  Uniform Resource Locator


   This property is identified by the property name URL. This property
   defines a Uniform Resource Locator (URL) associated with the
   iCalendar object. This property may MAY be specified in the event, to-do,
   journal, free/busy, "VEVENT",
   "VTODO", "VJOURNAL", "VFREEBUSY", and alarm "VALARM" calendar components.

   The property is defined by the following notation:




Dawson/Stenerson                   68                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     url        = "URL" ":" [ws] url CRLF

   The following is an example of this property:

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

   The data type for this property is URL.

5.6.37

4.6.38  Unique Identifier


   This property is identified by the property name UID. This property
   defines the persistent, globally unique identifier for the calendar
   component. The property must MUST be specified in the event, to-do "VEVENT", "VTODO"
   and
   journal "VJOURNAL" calendar components.

   The UID itself MUST be a globally unique identifier. The generator of
   the identifier MUST guarantee that the identifier is unique. There
   are several algorithms that can be used to accomplish this. The
   identifier is RECOMMENDED to be the identical syntax to the [RFC 822]
   addr-spec. A good method to assure uniqueness is to put the domain
   name or a domain literal IP address of the host on which the
   identifier was created on the right hand side of the "@", and on the
   left hand side, put a combination of the current calendar date and
   time of day (i.e., formatted in as a DATE-TIME value) along with some
   other currently unique (perhaps sequential) identifier available on
   the system (for example, a process id number). Using a date/time
   value on the left hand side and a domain name or domain literal on
   the right hand side makes it possible to guarantee uniqueness since
   no two hosts should be using the same domain name or IP address at
   the same time. Though other algorithms will work, it is RECOMMENDED
   that the right hand side contain some domain identifier (either of
   the host itself or otherwise) such that the generator of the message
   identifier can guarantee the uniqueness of the left hand side within
   the scope of that domain.

   This identifier is created by the calendar system that generates an
   iCalendar Object. object. The identifier is represented as a text value. This
   is the method for correlating scheduling messages with the referenced
   event, to-do, or journal.

   The property is defined by the following notation:

     uid        = "UID" [";" paramlist] ":" [ws] text CRLF

Dawson/Stenerson                   59              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   The following is an example of this property:

     UID:19960401-080045-4000F192713-0052

     UID:19960401T080045Z-4000F192713-0052@host1.com

   This property is an important method for group scheduling
   applications to match requests with later replies, modifications or
   deletion requests. Calendaring and scheduling applications must MUST
   generate this property in event, to-do "VEVENT", "VTODO" and journal "VJOURNAL" calendar




Dawson/Stenerson                   69                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   components to assure interoperability with other group scheduling
   applications.

   Implementations MUST be able to receive and persist values of at
   least 255 characters for this property.

   The data type for this property is TEXT.

5.6.38

4.6.39  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. memo. Extension properties are specified by property
   and/or property parameter names that have the prefix text of "X-"
   (the two character sequence: LATIN CAPITAL LETTER X character
   followed by the HYPEN-MINUS character). It is recommended RECOMMENDED that
   vendors concatenate onto this sentinel another short prefix text to
   identify the vendor. This will facilitate readability of the
   extensions and minimize possible collision of names between different
   vendors. User agents that support this content type are expected to
   be able to parse the extension properties and property parameters but
   may
   MAY ignore them.

   The property is defined by the following notation:

     extension  = "X-" [vendorid] "-" word [";" [ws] paramlist] ":" [ws]
                  value

     vendorid   = 1*char "-" 3*char        ;Vendor identification prefix text

   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 TEXT. Optionally, the data type may MAY be any of the other valid data
   types.

6.

5.      Recommended Practices


   These recommended practices should be followed in order to assure
   consistent handling of the following cases for an iCalendar object.

   1.      A calendar entry with a DTSTART "DTSTART" property but no DTEND "DTEND" property
     - The event does not take up any time. It is intended to represent
     an event that is associated with a given calendar date and time of
     day, such as an anniversary. Since the event does not take up any
     time, it must


Dawson/Stenerson                   60              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     not MUST NOT be used to record busy time no matter what the
     value for the
     TRANSP "TRANSP" property.




Dawson/Stenerson                   70                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   2.      When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
     "VTODO" calendar components, have the same value data type (e.g.,
     DATE-TIME), they should specify values in the same time format
     (e.g., local time with UTC offset).

   3.      A combination of RRULE "RRULE" and RDATE "RDATE" properties that produces more
     than one instance for a given date/time - Only one recurrence can
     occur on a given date/time interval. Just one instance for the
     date/time is recorded.

   3.

   4.      A particular calendar profile iCalendar object method that specifies ATTENDEE "ATTENDEE"
     properties with the MEMBER "MEMBER" property parameter, for which the
     recipient has multiple memberships - Recipient should reply to
     only the first
     MEMBER "MEMBER" property parameter value that it can
     match.

7.

6.      Registration of Content Type Elements


   This section provide the process for registration of MIME Calendaring
   and Scheduling Content Type profiles iCalendar object methods and new or
   modified properties.

7.1

6.1     Registration of New and ModifiedProfiles Modified iCalendar object Methods


   New MIME Calendaring and Scheduling Content Type profile types iCalendar object
   methods are registered by the publication of an IETF Request for
   Comment (RFC). Changes to a profile type an iCalendar object method are registered
   by the publication of a revision of the RFC defining the profile type.

7.2 method.

6.2     Registration of New Properties


   This section defines procedures by which new properties or enumerated
   property values for the MIME Calendaring and Scheduling Content Type
   can be registered with the IANA. Note that non-IANA properties may MAY be
   used by bilateral agreement, provided the associated properties names
   follow the "X-" convention.

   The procedures defined here are designed to allow public comment and
   review of new properties, while posing only a small impediment to the
   definition of new properties.

   Registration of a new property is accomplished by the following
   steps.

7.2.1

6.2.1   Define the property


   A property is defined by completing the following template.

     To: ietf-calendar@imc.org

     Subject: Registration of text/calendar MIME property XXX

     Property name:

     Property purpose:

     Property data type(s):

     Property encoding:



Dawson/Stenerson                   61                   71                  Expires January MAY 1998


Internet Draft       C&S Core Object Specification        July 29,     October 22, 1997


     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.

   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 MUST be precise and must not MUST NOT violate the general
   encoding rules defined in this document. memo.

   Property special notes: Any special notes about the property, how it
   is to be used, etc.

7.2.2

6.2.2   Post the Property definition


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

7.2.3

6.2.3   Allow a comment period


   Discussion on the new property must MUST be allowed to take place on the
   list for a minimum of two weeks. Consensus must MUST be reached on the
   property before proceeding to the next step.

7.2.4

6.2.4   Submit the property for approval


   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the property, the
   registration application should be submitted to the Profile Method Reviewer
   for approval. The Profile Method Reviewer is appointed to the Application
   Area Directors and may MAY either accept or reject the property
   registration. An accepted registration should be passed on by the
   Profile



Dawson/Stenerson                   72                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   Method Reviewer to the IANA for inclusion in the official IANA
   profile method
   registry. The registration may 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 Method Reviewer's decision to reject a property may MAY be
   appealed by the proposer to the IESG, or the objections raised can be
   addressed by the proposer and the property resubmitted.



Dawson/Stenerson                   62              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

7.3

6.3     Property Change Control


   Existing properties may MAY be changed using the same process by which
   they were registered.

        1.           Define the change

        2.           Post the change

        3.           Allow a comment period

        4.           Submit the property for approval

   Note that the original author or any other interested party may 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. memo. The Profile Method Reviewer may 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.

8.

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

9.

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

10.

9.      References


   The following document are referred to within this document. memo.

   [ICMS] "Internet Calendaring Model Specification", Internet-Draft,
   July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-
   00.txt.




Dawson/Stenerson                   73                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   [IMIP] "iCalendar Message-based Interoperability Protocol (IMIP)",
   Internet Draft, October 1997, http://www.imc.org/draft-ietf-calsch-
   imip-02.txt.

   [ISO 8601] ISO 8601, "Data elements and interchange formats-                                                              -
                                                               -
   Information interchange-                          -
                           -Representation 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
   Facilities--Registration Procedures for Public Text Owner
   Identifiers", Second Edition, International Organization for
   Standardization, April, 1991.


Dawson/Stenerson                   63              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

   ITIP-1]

   [ITIP] "iCalendar Transport-Independent Interoperability Protocol
   (iTIP) - Part 1: : Scheduling Events Events, Busy Time, To-dos and Busytime", Internet-Draft,
   July 1997, http://www.imc.org/draft-ietf-calsch-itip-part1-00.txt.

   [ITIP-2] "iCalendar Transport-Independent Interoperability Protocol
   (iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997,
   http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt.

   [ITIP-3] "iCalendar Transport-Independent Interoperability Protocol
   (iTIP) - Part 3: Scheduling Journal Entries", Entries ",
   Internet-Draft, July October 1997, http://www.imc.org/draft-ietf-calsch-itip-part3-00.txt. http://www.imc.org/draft-ietf-calsch-
   itip-01.txt.

   [MIME DIR] Howes, T., Smith, M., "A MIME Content-Type for Directory
   Information", Internet-draft-ietf-asid-mime-direct-06.txt, July,
   1997.

   [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, August 1982.

   [RFC 1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform
   Resource Locators (URL)", RFC 1738, December 1994.

   [RFC 1766] Alvestrand, H., "Tags for the Identification of
   Languages", March 1995.

   [RFC 1872] Levinson, E., "The MIME Multipart/Related Content-type,"
   RFC 1872, December 1995.

   [RFC1983] "Internet Users' Glossary", RFC 1983, August 1996.

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

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

   [RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
   Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
   November 1996.

   [RFC 2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet
   Mail Extensions (MIME) - Part Four: Registration Procedures", RFC
   2048, January
   2048, January 1997.




Dawson/Stenerson                   74                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


   [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
   RFC 2119, March 1997.

   [UTF-8] "UTF-8, a transformation format of Unicode and ISO
   10646",Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-
   drafts/draft-yergeau-utf8-01.txt.

   [VCARD] Internet Mail Consortium, "vCard - The Electronic Business
   Card Version 2.1", http://www.versit.com/pdi/vcard-21.txt, September
   18, 1996.

   [VCAL] Internet Mail Consortium, "vCalendar - The Electronic
   Calendaring and Scheduling Exchange Format",
   http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.




Dawson/Stenerson                   64              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

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

11.

10.     Acknowledgments


   A hearty thanks to the IETF Calendaring and Scheduling Working Group
   and also the following individuals who have participated in the
   drafting, review and discussion of this memo:

   Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John
   Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre
   Courtemanche, Dave Crocker, Alec Dun, John Evans, Ross Finlayson,
   Randell Flink, Flint, Ned Freed, Patrik Falstrom, Chuck Grandgent, Mark
   Handley, Steve Hanna, Paul B. Hill, Paul Hoffman, Ross Hopson, Mark
   Horton, Bruce Kahn, C. Harald Koch, Don Lavange, Theodore Lorek,
   Steve Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris
   Newman, John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes,
   Robert Ripberger, John Rose, Andras Salamar, Ted Schuh, Vinod
   Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg,
   William P. Spencer, John Sun, Mark Towfiq, Robert Visnov, James L.
   Weiner, Mike Weston, William Wyatt.

11.     Copyright




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



Dawson/Stenerson                   75                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


      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



     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
     TEL;WORK;MSG:+1-425-936-5522
     TEL;WORK;FAX:+1-425-936-7329
     EMAIL;INTERNET:deriks@Microsoft.com
     END:VCARD

   The iCalendar object is a result of the work of the Internet
   Engineering Task Force Calendaring and Scheduling Working Group. The
   chairman of that working group is:


Dawson/Stenerson                   65              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997

     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
     TEL;WORK;MSG:+1-248-559-5955
     TEL;WORK;FAX:+1-248-559-5034
     EMAIL;INTERNET:anik@ontime.com
     END:VCARD

13.     iCalendar Object object Examples


   The following examples are provided as an informational source of
   illustrative iCalendar objects consistent with this content type.

   The following iCalendar object is specified as the content of a MIME
   message. The example demonstrates a possible 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
     MIME-VERSION:1.0
     MESSAGE-ID:<id1@host1.com>
     CONTENT-TYPE:text/calendar;method=request

     BEGIN:VCALENDAR
     PROFILE:event-request
     METHOD:REQUEST
     PRODID:-//xyz Corp//NONSGML PDA Calendar Verson 1.0//EN
     VERSION:2.0
     BEGIN:VEVENT



Dawson/Stenerson                   76                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DTSTAMP:19960704T120000Z
     DTSTART:19960918T143000Z
     DTEND:19960920T220000Z
     CATEGORIES:CONFERENCE,PROJECT
     SUMMARY:Networld+Interop Conference
     DESCRIPTION;ENCODING=Q:Networld+Interop_Conference_
      and_Exhibit=0D=0A
     Atlanta_World_Congress_Center=0D=0A
     Atlanta,_Georgia
     DESCRIPTION:Networld+Interop Conference
       and Exhibit\nAtlanta World Congress Center\n
     Atlanta, Georgia
     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 1.0
     Message-ID: <id1@host1.com> <id2@host1.com>
     Content-Type: text/calendar;Profile=event,request text/calendar;method=request

     BEGIN:VCALENDAR
     PROFILE:event-request
     METHOD:REQUEST
     PRODID:-//RDU Software//NONSGML HandCal//EN
     VERSION:2.0


Dawson/Stenerson                   66              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
     BEGIN:VEVENT
     DTSTAMP:19961022T133000Z
     ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org
     DESCRIPTION:First IETF-Calendaring and Scheduling Working Group
       Meeting
     CATEGORIES:MEETING
     CLASS:PUBLIC
     CREATED:19961022T083000
     SUMMARY:IETF Calendaring Working Group Meeting
     DTSTART:19961210T210000Z
     DTEND:19961210T220000Z
     LOCATION:San Jose, CA - Fairmont Hotel
     UID:guid-1.host1.com
     END:VEVENT
     END:VCALENDAR


   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:1.0
     MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com>
     CONTENT-TYPE:text/calendar;PROFILE=event-request
     MESSAGE-ID:<id3@host1.com>
     CONTENT-TYPE:text/calendar;method=request





Dawson/Stenerson                   77                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     BEGIN:VCALENDAR
     PROFILE:event-request
     METHOD:REQUEST
     VERSION:2.0
     PRODID:-//ABC Corporation//NONSGML My Product//EN
     BEGIN:VEVENT
     DTSTAMP:19970324T1200Z
     SEQUENCE:0
     UID:19970324-080045-4000F192713-0052
     UID:19970324T080045Z-4000F192713-0052@host1.com
     ATTENDEE;EXPECT=REQUEST:jsmith@host1.com
     DTSTART:19970324T123000Z
     DTEND:19970324T210000Z
     CATEGORIES:CONFERENCE,PROJECT
     CLASS:PUBLIC
     SUMMARY:Calendaring Interop Conference
     DESCRIPTION;ENCODING=Q:Calendaring_Interop_
      Conference_and_Exhibit=0D=0A
      Atlanta,_Georgia
     DESCRIPTION:Calendaring Interop Conference and Exhibit\n
      Atlanta, Georgia
     LOCATION:Atlanta World Congress Center
     ATTACH;VALUE=URL:file://xyzCorp.com/conf/bkgrnd.ps
     ATTACH;VALUE=URL:file:///xyzCorp.com/conf/bkgrnd.ps
     END:VEVENT
     END:VCALENDAR

   Example of a reply to the above request, accepting the meeting.

     TO:jdoe@host1.com
     FROM:jsmith@host1.com
     MIME-VERSION:1.0
     MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com>
     CONTENT-TYPE:text/calendar;PROFILE=event-reply
     MESSAGE-ID:<id4@host1.com>
     CONTENT-TYPE:text/calendar;method=reply

     BEGIN:VCALENDAR
     PROFILE:event-reply


Dawson/Stenerson                   67              Expires January 1998


Internet Draft       C&S Core Object Specification        July 29, 1997
     METHOD:REPLY
     VERSION:2.0
     PRODID:-//ABC Corporation//NONSGML My Product//EN
     BEGIN:VEVENT
     DTSTAMP:19970324T120000Z
     SEQUENCE:0
     RESPONSE-SEQUENCE:0
     UID:19970324-080045-4000F192713-0052
     ATTENDEE;STATUS=CONFIRMED;EXPECT=REQUEST:jsmith@host1.com
     UID:19970324T080045Z-4000F192713-0052@host1.com
     ATTENDEE;STATUS=ACCEPTED;EXPECT=REQUEST:jsmith@host1.com
     END:VEVENT
     END:VCALENDAR

   An example of a meeting cancelation:

     TO:jsmith@host1.com
     FROM:jdoe@host1.com
     MIME-VERSION:1.0
     MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com>
     CONTENT-TYPE:text/calendar;PROFILE=event-cancel
     MESSAGE-ID:<id5@host1.com>
     CONTENT-TYPE:text/calendar;method=cancel

     BEGIN:VCALENDAR
     PROFILE:event-cancel
     METHOD:CANCEL
     VERSION:2.0
     PRODID:-//ABC Corporation//NONSGML My Product//EN
     BEGIN:VEVENT
     UID:19970324-080045-4000F192713-0052


Dawson/Stenerson                   78                  Expires MAY 1998


Internet Draft       C&S Core Object Specification     October 22, 1997


     DTSTAMP:19970324T120000Z
     UID:19970324T080045Z-4000F192713-0052@host1.com
     END:VEVENT
     END:VCALENDAR

14.     Full Copyright Statement


   "Copyright (C) The Internet Society (date).  All Rights Reserved.

   This document and translations of it MAY be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation MAY be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself MAY not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process MUST be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Dawson/Stenerson                   68                   79                  Expires January MAY 1998

----