Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_a_c/draft-ietf-calsch-sch-00.txt

Text File | 1996-11-26 | 91KB | 2,808 lines

Calendar Working Group                                   Derik Stenerson
INTERNET DRAFT                                                  Alec Dun
draft-ietf-calsch-sch-00.txt                                   Microsoft
Expires May 30, 1997                                   November 25, 1996


                 MIME application/calendar Content Type


Status of this Memo

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

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet- Drafts as reference
  material or to cite them other than as "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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  ftp.isi.edu (US West Coast).


Abstract

  This document defines a MIME message format for openly scheduling
  meetings with others across the Internet. This definition is
  independent of any particular scheduling application. A new MIME
  Content-Type "APPLICATION/CALENDAR" is defined to contain scheduling
  data, including appointments, appointment requests for single events,
  appointment requests for recurring events, appointment responses.  The
  scope of this revision of the draft is the MIME format for meeting
  requests and responses. This the "on the wire" format; no attempt is
  made to define the storage format for the calendar information.











Stenerson                                           [Page 1]



Internet-Draft                                      11/25/96



Table of Contents
1. Overview............................................................3
 1.1 Introduction .....................................................3
 1.2 Scope ............................................................3
 1.3 Appointment request/reply semantics ..............................4
2. Application/Calendar content type...................................5
 2.1 Purpose, inheritance .............................................5
 2.2 Registration .....................................................5
 2.3 General usage, issues, restrictions ..............................7
3. Appointment Requests................................................9
 3.1 Description ......................................................9
 3.2 Properties .......................................................9
 3.3 Usage Specifics .................................................28
 3.4 General Examples ................................................39
4. Appointment Responses..............................................42
 4.1 Description .....................................................43
 4.2 Properties ......................................................43
 4.3 Examples ........................................................44
5. Acknowledgements...................................................45
6. Author's Addresses.................................................46




























Stenerson                                           [Page 2]



Internet-Draft                                      11/25/96



1. Overview

1.1 Introduction

  With the recent explosion in Personal Information Management and
  electronic mail based Group Scheduling software, there is a clear and
  present need for a standard means for such software to inter-operate
  across the Internet. Individuals and groups in all parts of the world
  need to be able to communicate schedule information and arrange
  meetings with one another in order to conduct business. Given the ties
  to messaging that exist in the arena of group communication and
  scheduling, the MIME [RFC-1521] message format and its extensible
  architecture is an obvious choice for an infrastructure to base a
  means for transporting calendaring data across the Internet.

  This document defines a standard for using a new MIME Content-Type
  "application/calendar" to encapsulate meeting request and response
  data in a textual format.

  The "application/calendar" Content-Type defines a general framework
  and format for holding calendaring information in a simple "type:
  value" format. This format and value datatype definitions are based on
  the "application/directory" specification as defined in [MIME-DIR].
  Mechanisms are included to specify alternate character set, language,
  encoding and other meta-information. This document also  defines the
  procedure by which particular application/calendar Content-Type
  formats, called profiles, may be defined and registered, and the
  conventions such formats must follow. These profiles will be used to
  help applications processing the data to interpret it correctly. For
  example, profile will be used to define an appointment request and
  another will define an appointment response. It is expected that other
  documents will be produced that define formats for various
  applications.

1.2 Scope

  The scope of this draft is the base definition of the
  application/calendar MIME Content-Type, the definition of the profile
  format for appointment requests and responses, and to discuss the
  issues surrounding these concepts. This the "on the wire" format. No
  attempt is made to outline the storage format for the calendar
  information, the features that a scheduling application should
  support, nor any of the user interface characteristics of such
  calendaring and scheduling applications.




Stenerson                                           [Page 3]



Internet-Draft                                      11/25/96


1.3 Appointment request/reply semantics

1.3.1 Appointment Request

  An appointment is a collection of properties representing a range of
  time on a individual's or group's calendar that is associated with an
  activity or event, often involving interactions with other individuals
  or groups. For example, it may be a 1 hour conference call from 14:00
  to 15:00. Such an scheduled event is created by one individual (the
  organizer) requesting another individual or group (attendees) to
  participate in an activity at a particular time. To encapsulate such a
  request in a MIME message using the "application/calendar" Content-
  Type, we define a REQUEST profile to represent the required collection
  of attributes that make up a appointment request.

  Figure 1 describes the appointment request flow:

         +-------------+
         | Appointment |_____________\ Attendee(s)
         |   Request   |             /
         +-------------+

                Figure 1 : Appointment requests

  An appointment request can be for single event or for one which occurs
  more than once (recurring event). For example, weekly meetings could
  be described using a single appointment with a recurring pattern,
  thereby reducing the storage requirements.

1.3.2 Appointment Response

  Appointment response messages update attendance status for each
  attendee, and are issued by the attendee after receiving an
  appointment request.

  Figure 2 describes the appointment request/response flow:

         +-------------+
         | Appointment |_____________\ Attendee(s)
         |   Request   |             /     |
         +-------------+                   |
                                           |
                                    +-------------+
          Appointment /_____________| Appointment |
            Organizer \             |   Response  |
                                    +-------------+



Stenerson                                           [Page 4]



Internet-Draft                                      11/25/96


                Figure 2 : Appointment response

  Here, the appointment organizer issues an appointment request. The
  attendee receives the request and issues an appointment response back
  to the organizer.

  Note that appointment responses are not required for each appointment
  request, and in some cases, particularly informational appointment
  requests sent to a large group of people, the meeting organizer will
  find responses undesirable.



2. Application/Calendar content type

2.1 Purpose, inheritance

  The purpose of the "application" Content-Type as defined in section
  7.4 of [RFC-1521] is "for data to be processed by mail-based uses of
  application programs." Calendaring and scheduling data falls into this
  category as suggested by [RFC-1521]. The "application/calendar"
  Content-Type is used to hold textual calendaring and scheduling
  information. The MIME Calendar Content Type may utilize any of the
  standard MIME content header fields such as those defined by [RFC
  822], [RFC 1521], and [RFC 1766]

  The definition is fashioned after and borrows heavily from the
  application/directory Content-Type specification as defined in [MIME-
  DIR].

2.2 Registration

  The application/calendar is defined as follows, using the MIME media
  type registration template from [MIME-REG].

  To: [e-mail]
  Subject: Registration of MIME media type application/calendar

  MIME media type name: application

  MIME subtype name: calendar

  Required parameters: none

  Optional parameters: charset, profile




Stenerson                                           [Page 5]



Internet-Draft                                      11/25/96


  The "charset" parameter is as defined in [RFC-1521] for other body
  parts. It is used to identify the default character set used within
  the body part. Note that alternate character sets can be specified on
  a per value basis using the "charset" type parameter as specified for
  "contentline" in [MIME-DIR].

  The "profile" parameter is used as a guide to applications
  interpreting the information contained within the body part. It should
  not be used to exclude or require particular pieces of information
  unless a profile definition specifically calls for this behavior. The
  value of the "profile" parameter is defined as follows. Note that
  profile names are case insensitive (i.e., the profile name
  "Appointment" is the same as "APPOINTMENT" and "appointment" and
  "apPointMent").

        profile := x-token / iana-token

        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-token := <a publicly-defined extension token, registered

                       with IANA, as specified in Appendix A of this
                       document>

  Specific profiles definitions are discussed in detail in this
  document.

  Encoding considerations: As specified by the Content-Transfer-Encoding
  header field. Note that each value may also have an inline encoding
  associated with it. This encoding is independent of the encoding for
  the body part as a whole (i.e., inline encodings are performed first,
  then Content-Transfer-Encoding is applied to the entire body part).

  Security considerations:  Calendar item information may be public or
  private. This specification does not include any access control
  mechanism to guarantee data privacy on a per-property or per Content-
  Type basis. Also, properties used in this Content-Type may include
  references to Uniform Resource Locators that may be programmed
  resources. Implementers and users of this specification should be
  aware of the network security implications of accepting and parsing
  such information.

  Interoperability considerations: Applications and downstream customers
  of this data must understand the types of information within the
  Content-Type, as defined in this document.



Stenerson                                           [Page 6]



Internet-Draft                                      11/25/96


  Published specification: The published specification is as defined in
  this document.

  Person & email address to contact for further information:

  Derik Stenerson
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA  98052
  USA
  [e-mail]
  +1.206.936.5522

  Intended usage: COMMON

  Author/Change controller:

  Derik Stenerson
  Microsoft Corporation
  One Microsoft Way

  Redmond, WA  98052
  USA
  [e-mail]
  +1.206.936.5522

  Alec Dun
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA  98052
  USA
  [e-mail]
  +1.206.936.4544


2.3 General usage, issues, restrictions

  The "application/calendar" Content-Type is used to hold textual
  calendaring and scheduling information. The MIME Calendar Content Type
  may utilize any of the standard MIME content header fields

  Example:

       Content-Type: application/calendar; charset=iso-8859-1
       Content-Transfer-Encoding: quoted-printable
       Content-Language: de
       Content-ID: <[e-mail]>



Stenerson                                           [Page 7]



Internet-Draft                                      11/25/96


2.3.1 Use of the multipart/related Content-Type

  The multipart/related Content-Type can hold the application/calendar
  body part and additional body part(s) for content that already has a
  natural MIME representation. For example, along with the textual
  information describing the event, an appointment request could also
  include a map showing the location in the form of a JPEG image.

  The root body part within the multipart/related body part is specified
  as defined in [RFC-1872] by a "start" parameter, or it is the first
  body part in the absence of such a parameter. The root body part must
  have a Content-Type of "application/calendar". This part holds text
  information, optionally defines the name and source of the
  information, and makes reference to subsequent body parts holding
  additional text and/or non-text item property information via their
  URL Content-IDs as explained in [MIME-DIR]. Body parts referred to do
  not have to be in any particular order.

2.3.2 Body part Content

  In general, the format for the content is as described in the [MIME-
  DIR] "contentline". In simple terms, the content consists of one or
  more CRLF-separated lines. Each "contentline" or property is in the
  form of a simple "type: value" format. Specific exceptions, will be
  covered in detail in this document.

  The collection of "type: value" pairs included in the body part are
  used to define the calendaring data being transmitted. These type
  definitions, once they are defined, can be reused to defined unique
  types calendaring objects that convey specific meaning when
  interpreted together. The Content-Type "profile" parameter is used to
  name this unique object, so applications can properly interpret the
  meaning calendaring data enclosed within the body part. Profiles are
  for appointment requests and responses are defined in this document.

  A application/calendar body part can only contain one calendaring
  object. For example, one appointment request or one appointment
  response per application/calendar body part. If the sending agent
  wishes to enclose multiple requests in a single message, multiple body
  parts should be used, using the multipart/mixed MIME Content-Type.
  This has an added advantage in that if the client is using IMAP as the
  access protocol, it could access individual appointments from the
  message by body part.

  Note that the *types* of the properties (text, d-t, bool) are also
  defined in [MIME-DIR].



Stenerson                                           [Page 8]



Internet-Draft                                      11/25/96



3. Appointment Requests

3.1 Description

  The Appointment REQUEST content profile definition

       Profile name: REQUEST

       Profile purpose: Indicates schema of REQUEST item

       Profile intended usage: COMMON

  Example:

  Content-Type: application/calendar; profile="request"


3.2 Properties

  An Appointment Request is made up of a collections of properties,
  which are grouped logically according to function below.

  Appointment time properties: The appointment time properties describe
  the start and end time of the appointment, including time zone
  information (either explicit or encoded), and optionally including
  recurrence pattern information to describe a repeating event. The time
  properties required for an appointment are:

            Start
            End

  and the Recurrence Pattern property names, all of which are defined
  above in Section 3.2.3:

            RPDescr
            DW
            DM
            DY
            WY
            MY
            HI
            DI
            WI
            MI
            YI
            TStartInst


Stenerson                                           [Page 9]



Internet-Draft                                      11/25/96


            TEndInst
            DStart
            DEnd
            DExcept
            DOrigExcept
            TZID
            TZBias
            TZDstBias
            TZStdBias
            TZStdTrans
            TZDstTrans
            TZDS
            TZSrc
            CalTypeID

  Core appointment properties: These properties are the base components
  that make up an appointment, some of which are optional.

            Description
            Summary
            Location
            Resources
            Confidentiality
            Priority
            Category

  Attendees: Properties that represent the individuals or groups that
  will participate in the activity.

            AttendReq
            AttendOpt
            AttendFyi
            AttendOwner

  Appointment data processing properties: appointment attributes used in
  processing the scheduling data.

            ID
            ApptVersion
            ApptID
            Rsvp
            RequestType


3.2.1 Example: Simple meeting request.




Stenerson                                          [Page 10]



Internet-Draft                                      11/25/96


  This example demonstrates a simple appointment request in the
  application/calendar MIME Content-Type.

     To: Larry <[e-mail]>, Curly <[e-mail]>,
      Moe <[e-mail]>
     From: Shemp <[e-mail] >
     Subject: Hey, we need to make some money!
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="request"

     Start;value=d-t: 22 Oct 1996 17:00:00 UT
     End;value=d-t: 22 Oct 1996 19:30:00 UT
     ID: <[e-mail]>
     Location: Conference Room 3384
     Categories: Business
     Categories: Review
     Summary: A new plan
     Resources: Projector
     Resources: VCR
     Resources: Rubber Mallet
     Description: Let's make a new plan. Any conflicts will be
      resolved the Rubber Mallet. Nuk! Nuk! Nuk!"

  This example shows a simple one time meeting request, using a variety
  of the optional properties.

3.2.2 appointment time properties

  The single instance start and end date time property names are defined
  below:

3.2.2.1 Start

        Name: Start
        Data type: D-T
        Purpose: Start date and time of the item, in UTC.
        Encoding:
        Required: YES
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.2.2 End

        Name: End
        Data type: D-T


Stenerson                                          [Page 11]



Internet-Draft                                      11/25/96


        Purpose: End date and time of the item in UTC.
        Encoding:
        Required: YES
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.3 Recurrence Properties


3.2.3.1 DW

        Name: DW
        Data type: TEXT
        Purpose: (DaysOfWeek) A list of the individual days of the week
               that the appointment can occur.
        Encoding:  Sun, Mon, Tue, Wed, Thu, Fri, Sat.  The values are
               case insensitive and non-localizable.
        Special notes: For example: A recurring weekly Appointment that
               occurs on Monday and Wednesday sets DW equal to "Mon,
               Wed".
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: COMMON


3.2.3.2 DM

        Name: DM
        Data type: INT
        Purpose: (DaysOfMonth)
                 A list of the individual days of the month that the
                 appointment can occur.
        Encoding:  1 to 31 / -31 to -1. 0 is undefined.
        Special notes: Negative values specify an offset from the end
                 of the month.  Negative one is the last day of the
                 month.  For example, a recurring monthly Appointment
                 that occurs on the first and tenth days sets
                 DM equal to "1, 10".
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: COMMON


3.2.3.3 DY

        Name: DY


Stenerson                                          [Page 12]



Internet-Draft                                      11/25/96


        Data type: INT
        Purpose: (DaysOfYear)
                 A list of the individual days of the year that the
                 appointment can occur.
        Encoding:  1 to 366 / -366 to -1. 0 is undefined.
        Special notes: Negative values specify an offset from the end
                 of the year.  Negative one is the last day of the
                 year.  For example, a recurring yearly Appointment
                 that occurs on the forty-first and two hundredth days
                 sets DY equal to "41, 200".
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: LIMITED USE



3.2.3.4 WY

        Name: WY
        Data type: INT
        Purpose: (WeeksOfYear)
                 A list of the individual weeks of the year that the
                 appointment can occur.
        Encoding: 1 - 53
        Special notes: For example, a recurring appointment that occurs
                 in the fourth and twenty-fifth weeks sets WY
                 equal to "4, 25".
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: LIMITED USE


3.2.3.5 MY

        Name: MY
        Data type: INT
        Purpose: (MonthsOfYear)
                 A list of the individual months of the year that the
                 appointment can occur.
        Encoding: 1 - 12
        Special notes: For example, a recurring appointment that occurs
                 in the fourth and tenth months sets MY equal
                 to "4, 10".
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON



Stenerson                                          [Page 13]



Internet-Draft                                      11/25/96



3.2.3.6 HI

        Name: HI
        Data type: TIME
        Purpose: (HourInterval)
                 Interval between hours for a recurrence pattern.
        Encoding:
        Special notes:
                 Time Zone information, if specified as part of time
                 is ignored.
               For example, run security sweep every 45 minutes, HI =
               00:45
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.3.7 DI

        Name: DI
        Data type: INT
        Purpose: (DayInterval)
                 Interval between days for a recurrence pattern.
        Encoding:
        Special notes: For example, every other day has
                 DI = 2.
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.3.8 WI

        Name: WI
        Data type: INT
        Purpose: (WeekInterval)
                 Interval between weeks for a recurrence pattern.
        Encoding:
        Special notes: For example, pay day every two weeks has a
                       WI of 2.
                       When the value of WI is 5 and is combined with
                       MI, WI it takes on the meaning of "Last". For
                       Example, to specify the last weekday of the
                       month:
                         WI: 5
                         MI: 1


Stenerson                                          [Page 14]



Internet-Draft                                      11/25/96


                         DW: Mon, Tue, Wed, Thu, Fri

        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.3.9 MI

        Name: MI
        Data type: INT
        Purpose: (MonthInterval)
                 Interval between months for a recurrence pattern.
        Encoding:
        Special notes: For example, a quarterly appointment, every
                  three months, has a MI of 3. Property
                  taxes, due every six months, have a MI
                  of 6.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.3.10 YI

        Name: YI
        Data type: INT
        Purpose: (YearInterval)
                 Interval between years for a recurrence pattern.
        Encoding:
        Special notes: For example, the Summer Olympics have a
                  YI of 4.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON

3.2.3.11 TStartInst

        Name: TStartInst
        Data type: Time
        Purpose: Start time for the appointment within the recurring
                 pattern.
        Encoding: local time or UTC is acceptable
        Special notes: if absent, the appointment is assumed to start
                 at 00:00:00 on the date specified for DStart.
        Required: NO
        Multi-valued: SOMETIMES


Stenerson                                          [Page 15]



Internet-Draft                                      11/25/96


        Intended usage: COMMON


3.2.3.12 TEndInst

        Name: TEndInst
        Data type: Time
        Purpose: End time for the appointment within the recurring
                 pattern.
        Encoding: local time or UTC is acceptable
        Special notes: if absent, the appointment is assumed to end
                 at 23:59:59 on the date specified for DEnd.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.3.13 DStart

        Name: DStart
        Data type: DATE
        Purpose: Start date for the recurring pattern.
        Encoding: The time zone information is specifically not
                  required in date format. Instead it is specified
                  separately as an unambiguous set of rules that can be
                  interpreted easily by the recipient.  If the time
                  zone is specified in the date format, the time zone
                  rules should have precedence.
        Required: YES
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.3.14 DEnd

        Name: DEnd
        Data type: DATE
        Purpose: End date for the recurrence pattern.
        Encoding: The time zone information is specifically not
                  required in date format. Instead it is specified
                  separately as an unambiguous set of rules that can be
                  interpreted easily by the recipient.  If the time
                  zone is specified in the date format, the time zone
                  rules should have precedence.
        Special notes: DEnd will be used to calculate the number of
                  transitions in and out of DST that must be listed as
                  part of the time zone rules for the recurring


Stenerson                                          [Page 16]



Internet-Draft                                      11/25/96


                  appointment.
        Required: YES
        Multi-valued: NEVER
        Intended usage: COMMON

3.2.3.15 RPDescr

        Name: RPDescr
        Data type: TEXT
        Purpose: Human-readable definition of recurrence pattern.
        Encoding:
        Special notes: Some examples of this string are
                      "Every 3 months, on the 12th day, from 12/1/96"
                      "Every week on Wednesday from 7/10/96 to
                      12/31/96"
                      This property is highly-recommended when sending
                      a recurring appointment request so clients have
                      a text description of the pattern to display.
        Required: NO

        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.3.16 DExcept

        Name: DExcept
        Data type: DATE
        Purpose: Instance date of an exception to the recurring
                 pattern.
        Encoding:
        Special notes: An exception is an appointment or appointments
                 that are excluded from a recurrence pattern.
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: COMMON


3.2.3.17 DOrigExcept

        Name: DOrigExcept
        Data type: DATE
        Purpose: Original Instance date of the exception to the
                 recurrence pattern.
        Encoding:
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


Stenerson                                          [Page 17]



Internet-Draft                                      11/25/96




3.2.3.18 StartOfWeek

        Name: StartOfWeek
        Data type: TEXT
        Purpose: A list of the individual days of the week that the
                 week can start on.
        Encoding:  Sun, Mon, Tue, Wed, Thu, Fri, Sat.  The values are
                 case insensitive and non-localizable.
        Special notes: For example:
                       European calendar often start on Monday.
                       This is only required for calculating patterns
                       when the week interval is greater than one.
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: COMMON


3.2.3.19 TZID

        Name: TZID
        Data type: TEXT
        Purpose: An ID that can be used to identify the time zone
                 (could be a name, a number, likely that we want an
                  IANA registry of time zone/daylight rule names)
        Encoding:
        Special Notes:
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.3.20 TZBias

        Name: TZBias
        Data type: TEXT
        Purpose: time delta from UTC  (e.g. +08:00)
        Encoding: [sign] hour, as defined in [RFC-822]
        Special Notes: if a sign "-" is not specified, it is
                       assumed to be a positive value
        Required: YES
        Multi-valued: NEVER
        Intended usage: COMMON





Stenerson                                          [Page 18]



Internet-Draft                                      11/25/96


3.2.3.21 TZDstBias

        Name: TZDstBias
        Data type: TEXT
        Purpose: time delta used in "Daylight Savings Time",
                 e.g. -01:00 (one hour)
        Encoding: [sign] hour, as defined in [RFC-822]
        Special Notes: if a sign "-" is not specified, it is
                       assumed to be a non-negative value.
                       Can be omitted, if the value is -01:00.
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.3.22 TZStdBias

        Name: TZStdBias
        Data type: TEXT
        Purpose: time delta used in "Standard Time",
                 e.g. 00:00
        Encoding: [sign] hour, as defined in [RFC-822]
        Special Notes: if a sign "-" is not specified, it is
                       assumed to be a non-negative
                       can be omitted if the value is 0, but should be
                       respected if present
        Required: NO
        Multi-valued: NEVER
        Intended usage: LIMITED USE


3.2.3.23 TZStdTrans

        Name: TZStdTrans
        Data type: D-T (date-time)
        Purpose: a generated list of one or more date-time values that
                 describe the transition to Standard Time for the
                 duration of the recurring pattern.
        Encoding:
        Special Notes: Client implementers may want to restrict the
                 end date for a recurring pattern to limit the number
                 of items in the list.
                 Not required if no transitions are used.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON



Stenerson                                          [Page 19]



Internet-Draft                                      11/25/96



3.2.3.24 TZDstTrans

        Name: TZDstTrans
        Data type: D-T (date-time)
        Purpose: a generated list of one or more date-time values that
                 describe the transition to Daylight Savings Time
                 for the duration of the recurring pattern.
        Encoding:
        Special Notes: Client implementers may want to restrict the
                 end date for a recurring pattern to limit the number
                 of items in the list.
                 Not required if no transitions are used.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.3.25 TZDS

        Name: TZDS
        Data type: DATE
        Purpose: A date stamp to indicate the freshness of this time
                 zone definition. Could be used by the recipient
                 application to decided whether to use this data or
                 attempt to use a newer rule.
        Encoding:
        Special Notes:
        Required: NO
        Multi-valued: NEVER
        Intended usage: LIMITED USE


3.2.3.26 TZSrc

        Name: TZSrc
        Data type: URL
        Purpose: URL to approved IANA time zone specification
                 information. Using this client may attempt to gather
                 more up to date time zone information.
        Encoding:
        Special Notes:
        Required: NO
        Multi-valued: NEVER
        Intended usage: LIMITED USE




Stenerson                                          [Page 20]



Internet-Draft                                      11/25/96


3.2.3.27 CalTypeID

        Name: CalTypeID
        Data type: TEXT
        Purpose: an identifier for the reference Calendar.  Choice
                 of calendar will affect date specifications and
                 recurrence patterns
        Encoding: one of the following case insensitive values
               "Gregorian".  Other types yet to be defined
        Special Notes: "Gregorian" is assumed if not specified
                       If a unrecognized/unsupported calendar type is
                       received, the client should issue an appropriate
                       error.
                       It is expected that additional calendar types
                       will need to be defined and registered.
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.4 Core appointment properties


3.2.4.1 Description

        Name: Description
        Data type: TEXT default, URL
        Purpose: A user-specified description of the appointment.
        Encoding:
        Special notes: This property is intended to accommodate more
                       verbose descriptions than the Summary property.
                       For example, it could be used to keep the agenda
                       for a meeting.
                       This property may refer to another MIME body
                       part. In particular, a URL to an HTML body part
                       would give you the ability to have a rich-text
                       description.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON



3.2.4.2 Summary

        Name: Summary
        Data type: TEXT
        Purpose: A brief description of the appointment


Stenerson                                          [Page 21]



Internet-Draft                                      11/25/96


        Encoding: This property SHOULD NOT include line breaks
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.4.3 Location

        Name: Location
        Data type: TEXT
        Purpose: Describes the location of the appointment
        Encoding:
        Special notes: [none]
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.4.4 Resources

        Name: Resources
        Data type: TEXT
        Purpose: Contains resources needed for the appointment
        Encoding:
        Special Notes: Possible resources include,
                       Projector
                       VCR
                       Computer
                       Coffee Machine
                       Car
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: COMMON


3.2.4.5 Confidentiality

        Name: Confidentiality
        Data type: TEXT
        Purpose: Rating of appointment's confidentiality.
        Encoding: Three possible values are defined.
                  "Public": Item is viewable by all users, subject to
                            global security restrictions of the system.
                            The item affects free-busy time
                            calculations and display.
                  "Private": Item is not viewable by all users, subject
                            to security restrictions of the system.


Stenerson                                          [Page 22]



Internet-Draft                                      11/25/96


                            The item affects free-busy time
                            calculations and display.
                  "Confidential": Item is not viewable by all users,
                            subject to security restrictions of the
                            system. The item does not affect free-busy
                            time calculations and display.
                  All values are case insensitive.
        Special notes: Absence of this property indicates that the item
                       is "Public".
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.4.6 Priority

        Name: Priority
        Data type: INT
        Purpose: Denotes appointment priority
        Encoding: This value should not be negative
        Special Notes: Smaller values denote higher priority.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.4.7 Category

        Name: Category
        Data type: TEXT
        Purpose: Contains appointment categorisations
        Encoding:
        Special Notes: Possible categories include,
                       Education
                       Holiday
                       Meeting
                       Miscellaneous
                       Phone Call
                       Sick Day
                       Special Occasion
                       Travel
                       Vacation
                       Business
                       Personal
        Required: NO
        Multi-valued: ALWAYS
        Intended usage: COMMON


Stenerson                                          [Page 23]



Internet-Draft                                      11/25/96




3.2.5 Attendee properties.


3.2.5.1 AttendReq

        Name: AttendReq
        Data type: TEXT default, URL
        Purpose: Optional property used to list required attendees.
        Encoding:
        Special notes: If the property is absent, it is assumed that
                       the recipients on the [RFC 822]"To:" header
                       are the required recipients.
                       If on the other hand, the property is present,
                       the recipients listed in the "To:" header are
                       ignored.
                    This may be a multi-valued [RFC-822] recipient
                       list, or it may be of type URL, referring to a
                       vCard object, for example, to allow access to
                       more data than just the address.
                        Multiple attendees may be specified by including
                        multiple instances of this property within the
                        MIME calendaring entity.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON

3.2.5.2 AttendOpt

        Name: AttendOpt
        Data type: TEXT default, URL
        Purpose: Optional property used to list optional attendees.
        Encoding:
        Special notes: If the property is absent, it is assumed that
                       the recipients on the [RFC 822]"Cc:" header
                       are the required recipients.
                       If on the other hand, the property is present,
                       the recipients listed in the "Cc:" header are
                       ignored.
                    This may be a multi-valued [RFC-822] recipient
                       list, or it may be of type URL, referring to a
                       vCard object, for example, to allow access to
                       more data than just the address.
                        Multiple attendees may be specified by including
                        multiple instances of this property within the
                        MIME calendaring entity.


Stenerson                                          [Page 24]



Internet-Draft                                      11/25/96


        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.5.3 AttendFyi
  Name: AttendFyi
        Data type: TEXT default, URL
        Purpose: Optional property used to list attendees to receive
                 the request as a "for your information" (FYI)
        Encoding:
        Special notes: If the property is absent, it is assumed that
                       the recipients on the [RFC 822]"Bcc:" header
                       are the required recipients.
                       If on the other hand, the property is present,
                       the recipients listed in the "Bcc:" header are
                       ignored.
                    This may be a multi-valued [RFC-822] recipient
                       list, or it may be of type URL, referring to a
                       vCard object, for example, to allow access to
                       more data than just the address.
                        Multiple attendees may be specified by including
                        multiple instances of this property within the
                        MIME calendaring entity.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.5.4 AttendOwner

        Name: AttendOwner
        Data type: TEXT default, URL
        Purpose: Optional property used to list the owner(s) attendees.
        Encoding:
        Special notes: If the property is absent, there is no owner(s).
                    This may be a multi-valued [RFC-822] recipient
                       list, or it may be of type URL, referring to a
                       vCard object, for example, to allow access to
                       more data than just the address.
                        Multiple attendees may be specified by including
                        multiple instances of this property within the
                        MIME calendaring entity.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON



Stenerson                                          [Page 25]



Internet-Draft                                      11/25/96



3.2.6 Appointment data processing property name definitions

3.2.6.1 ID

        Name: ID
        Data type: TEXT
        Purpose: Unique ID for the parent item
        Encoding: ID format is the same as MessageID, as described in
                  [RFC 822]
        Special notes: An ID is necessary to correlate responses with
                  appointment requests and recurrence exceptions with
                  parent recurrences.
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.6.2 ApptVersion

        Name: ApptVersion
        Data type: D-T
        Purpose: Datetime of the last change to the appointment that
                 would invalidate attendee responses prior to the
                 change. An example of such a change is the
                 rescheduling of an appointment.
        Special notes: Absence of this property implies that all
                 attendees' responses are valid.
        Encoding:
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON

3.2.6.3 ApptID

        Name: ApptID
        Data type: TEXT
        Purpose: ID of the parent recurring item.
        Special note: If an appointment needs to be rescheduled, the
                      client generates a new appointment request with
                      the ApptID property equal to the original
                      appointment's ID property. Recipients need to
                      verify whether an appointment request is for a
                      new appointment, cancellation, or rescheduled
                      appointment.
        Encoding: ApptID format is the same as MessageID, as
                  described in [RFC 822]


Stenerson                                          [Page 26]



Internet-Draft                                      11/25/96


        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.2.6.4 Rsvp

        Name: Rsvp
        Data type: BOOL
        Purpose: Flag denoting whether the appointment organizer
                 requests an attendance response from appointment
                 attendees.
        Encoding:
        Special notes: TRUE = response is requested,
                       FALSE = response is not requested.
                       Some appointments do not require
                       attendance tracking or the organizer
                       does not care. This property should
                       be set accordingly.
                       If the property is absent, it is
                       assumed FALSE.
        Required: NO
        Multi-valued: SOMETIMES
        Intended usage: COMMON


3.2.6.5 RequestType

        Name: RequestType
        Data type: TEXT
        Purpose: Indicates the type of the request.
        Encoding: One of the following values:
                  "Request" Request to attend appointment.
                  "Cancel"  Request to cancel appointment.
                  Values are case insensitive.
        Special Notes:  If the value is absent, "Request" is assumed.
        Required: NO
        Multi-valued: NEVER
        Intended usage: COMMON


3.3 Usage Specifics

  Here is some additional information on constructing and sending
  meeting requests.




Stenerson                                          [Page 27]



Internet-Draft                                      11/25/96


3.3.1 Date, Time, and Time zone issues

3.3.1.1 Introduction

  Before defining the collection of properties used to specify the
  appointment, a discussion of the requirements for specifying event
  time is required. Representing the time and date in an unambiguous
  manner such that all recipients can accurately interpret it is
  critical for scheduling applications. The problem of specifying a date
  and time is simple when an event and all attendees are in one
  location. However, when the attendees and location span multiple time
  zones, more care is required to accurately communicate a fixed time
  due to the variety of rules that define these time zones, and is
  additionally complicated by the fact that over time these rules change
  in unpredictable ways (government edict, etc.).


3.3.1.2 Definitions

  Before continuing the discussion, here are some useful definitions:
  .  Local time: The "by the clock time" for your location.
  .  Time zone bias: The time delta from the local time at the zero
     (prime) meridian, usually in hours and minutes, based roughly on
     the difference in longitude of your location and the zero meridian
     (every 15 degrees of longitude represents one hour)
  .  Standard Time (ST) bias: Rarely, if ever used. The time delta used
     in calculating Standard Time.
  .  Daylight Savings Time (DST) bias: The time delta used in
     calculating DST. Usually -60 minutes.
  .  Standard Time Transition: The rule that describes when the
     transition to ST starts.  Can be a pattern such as "Last Sunday in
     October at 2:00:00 AM", or a specific date and time. Not all zones
     switch on the same day and time, in there are 17 or more different
     rules.
  .  Daylight Savings Time Transition: The rule that describes when the
     transition to DST starts.  Can be a pattern such as "First Sunday
     in April at 2:00:00 AM", or a specific date and time.
  .  Coordinated Universal Time (UTC): Often used as a means to specify
     time in a unambiguous manner. UTC = local time + Bias, where Bias
     is either(Time zone bias + ST bias) or (Time zone bias + DST bias).

     For example, UTC for 9am Pacific Standard Time is

       UTC = 0900 + 0800 + 0 = 1700

     And, UTC for 9am Pacific Daylight Savings Time is



Stenerson                                          [Page 28]



Internet-Draft                                      11/25/96


       UTC = 0900 + 0800 + (-0100) = 1600

  .  A note on GMT vs UTC: Greenwich Mean Time (GMT) is a 24 hour
     astronomical time system based on the local time at Greenwich,
     England. GMT can be considered equivalent to Coordinated Universal
     Time (UTC) when fractions of a second are not important. However,
     by international agreement, the term UTC is recommended for all
     general timekeeping applications, and use of the term GMT is
     discouraged.

3.3.1.3 Single Event Date and Time Specification

  Despite the complexity of rules time zones, specifying a single event
  time in an unambiguous manner is fairly simple.  Given that the event
  time needs to be interpreted by user agents in multiple time zones,
  the event time must be described in a manner that allows the recipient
  agent to interpret the time in relation to the recipient's own time
  zone. Specifying the time of the appointment in local time only is not
  workable, in that the recipient agent would have to have accurate
  knowledge of both the event's time zone and his own time zone to
  calculate the correct time value for the recipient's schedule.
  Specifying the event's local time, plus the event's time zone
  information is workable, but requires more data and to be transmitted
  and more calculations required by the recipient. Instead, event
  start/end time and date can be specified by sender in Coordinated
  Universal Time (UTC), calculated based on the current known rules for
  the time zone and the date/time of the event. Then the recipient agent
  need only convert from UTC to its local time using the rules for his
  time zone.

3.3.1.4 Recurring Event Date and Time Specification

  The main issue that requires the event date and time specification for
  recurring events more complicated is that these events may be defined
  such that they cross the boundaries of a daylight transition (ST to
  DST and back).  For example, an recurring appointment at 08:00 should
  remain at 08:00 regardless of the daylight transitions that may
  happen.

  A recurring event can be specified with the following properties. For
  clarity a description is provided with property names in parenthesis
  (). Full definitions of the property names will be covered in section
  3.2.

  1) Event date and time, relative to a particular time zone. Could be
     UTC, but will often be local time. (TStartInst,
     TEndInst, DStart, DEnd, StartOfWeek)


Stenerson                                          [Page 29]



Internet-Draft                                      11/25/96



  2) Time zone Id (TZID): An ID that can be used to identify the time
     zone (could be a name, a number, likely that we want an IANA
     registry of time zone/daylight rule names.  Needs to be defined)

  3) Time zone Rules, composed of the following:
     a) Time zone Bias (TZBias): time delta from UTC  (e.g. 08:00)
     b) Daylight Bias (TZDstBias): time delta used in "Daylight
        Savings Time", e.g. -01:00 (one hour)
     c) Optional Standard Bias (TZStdBias): time delta used in
        "Standard Time". Should be 0 everywhere, but could be non-zero.

  4) Transition Rules, not required if no transitions are in use,
     composed of the following:
     a) Standard Transition (TZStdTrans): a list of absolute date/times
        bounded by the end date of the recurrence pattern
     b) Daylight Transition (TZDstTrans): a list of absolute
        date/times bounded by the end date of the recurrence pattern

  5) Optional Calendar Type identifier (CalTypeID).  Gregorian should be
  assumed if absent.  Alternate calendar types may require alternate
  date/time formats and recurrence pattern definitions.

  6) Optional Time Zone Date Stamp (TZDS): A date stamp to indicate the
  freshness of this time zone definition. Could be used by the recipient
  application to decided whether to use this data or use to a newer
  rule.

  7) Optional URL (TZSrc) to approved IANA time zone specification
  information.  (Client app Use the standard (that we define) for the
  time zone label to translate to a URL.?)

  8) recurrence pattern for the repeating events

  Explanation:

  Given the event time, the time zone bias values, and the transition
  rules, the recipient can accurately translate the event time into the
  proper value for the recipient time zone.  The even time (TStartInst,
  TEndInst) could be either local time or UTC -- given either, it is
  possible to calculate the other provided that the time zone
  information/rules are available.

  The time zone information is specifically not required in date format
  for DStart and DEnd. Instead it is specified separately as an
  unambiguous set of rules that can be interpreted easily by the



Stenerson                                          [Page 30]



Internet-Draft                                      11/25/96


  recipient.  If the time zone is specified in the date format, the time
  zone rules should have precedence.

  Time zone rules assume that UTC = local time + Bias, where Bias is one
  of (Time zone Bias + Std Bias) or (Time zone Bias + Daylight Bias).

  Daylight Bias (TZDstBias) can be omitted, if the value is -0100.

  Standard Bias (TZStdBias) can be omitted if the value is 0, but should
  be respected if present.

  If Time zone (TZBias), Standard (TZStdBias) and Daylight (TZDstBias)
  Bias are 0, the time should be interpreted as UTC.

  Transition Rules (TZStdTrans, TZDstTrans) should be omitted if there
  are no transitions or if a single event is specified.

  The presence of the Calendar Type (CalTypeID) allows the sender to
  express the recurrence pattern in another calendar type (for example
  Hijri). Absence of the Calendar type means Gregorian.  If a recipient
  is unable to handle the calendar type sent, it should do something
  reasonable.

  Recipients of event descriptions MAY make use of the time zone
  identifier TZID (for example, to correct for outdated DST rules), but
  creators of event descriptions SHOULD NOT assume that recipients will
  look at the time zone identifier.

  Recipients of event descriptions MAY make use of the time zone source
  URL (TZSrc) (for example, to correct for outdated DST rules), but
  creators of event descriptions SHOULD NOT assume that recipients will
  look at the time zone source URL identifier.

  Aside: Absence of time zone information altogether in a repeating
  event could indicate that this is a floating event (i.e. not tied to a
  time zone), e.g. I go running at 0700 no matter where I am in the
  world. However, this is NOT specified as valid in this standard as the
  author cannot imagine a situation where group scheduling could make
  use of this feature. However, a feature rich client application may
  allow a user to create such an appointment for personal scheduling.

3.3.1.5 Time zone of meeting

  One interesting aspect of meeting requests is what time zone should be
  used when scheduling the meeting.  This applies to both single and
  recurring meetings.



Stenerson                                          [Page 31]



Internet-Draft                                      11/25/96


  For example, if I schedule a weekly meeting at 9am and in my locale,
  there is no daylight savings time, but in your locale there is, then
  if my time zone was used to schedule the meeting, then the meeting
  would be 9am all the time for me, but 9am during the winter and 8am
  during the summer for you.

  There can be arguments made for the time being always 9am in my time,
  or always 9am in your time.  We could pick an arbitrary rule and say
  that the sender of the meeting's time zone is used, however in the
  case where we are both going to a meeting in another city, we'd
  probably want to use the time zone of where we are meeting.

  Ultimately the time zone that should be used comes down to a
  preference of the organizer and the attendees.  The key requirement is
  that the meeting must occur at the same time for all attendees.  Given
  this, from a coordination standpoint, it is unimportant which time
  zone is used, as long as everyone knows when the meeting is.  As an
  option, the application could allow the user to manually pick the time
  zone that should be used for the meeting.


3.3.1.6 Changes to local time zone shift rules

  Another issue that must be discussed is how to handle changes to time
  zone shift rules.  These don't happen all that often, but they need to
  be discussed.

  For a single event specified in UTC, a time zone shift rule change may
  change the apparent time of the meeting.  For example, if a local
  government changed from using daylight savings time to not using
  daylight savings time, then a meeting scheduled at 9:00am local time
  may change to 8:00am relative to attendees of the meeting who are
  located in the time zone that changed.

  There are a couple recommended ways a change like this can be handled.
  The first would be to prompt the creator of the meeting to reschedule
  the meeting, or allow an attendee of the meeting to ask that the
  meeting be rescheduled.  Another would be to automatically reschedule
  the meeting if the software detected a time zone rule change, although
  this may be problematic if the other attendees are busy at the new
  time.

  For a recurring event, a time zone shift may also change the apparent
  time of the meeting.  The same recommendations for handling time zone
  shift rule changes for single events also will work for recurring
  events.



Stenerson                                          [Page 32]



Internet-Draft                                      11/25/96


  Although this is beyond the scope of this draft, it may also be useful
  for applications to have access to a server from which time zone rule
  information can be easily retrieved.

  Example: UTC and Time Zone Rule change and the ambiguity

  Suppose I'm in Seattle (UTC-0800 Pacific Time) and you are in another
  time zone. I book a conference call with you at 9am on April 30 in
  Seattle. The UTC for April 30 9am is 1600 based on the rules for
  Daylight Savings Time (See example calculations above in the
  definitions). Now suppose that the rule for Seattle's transition to
  DST change after I've booked this appointment such that the transition
  date to DST is now after April 30.  9am on April 30 in Seattle is now
  calculated as 1700 UTC, because the appointment is no longer in DST.
  However, your schedule knows of this appointment by 1600 UTC, not 1700
  UTC, so we're out of synchronization; if I want to  keep this
  appointment I need to adjust my calendar to reflect that this
  appointment is now at 8am my time (1600 UTC using the Standard Time
  rule). I may simply want my schedule to adjust the appointment so that
  the meeting time has effectively changed; after all, when I booked the
  call with you at 1700 UTC, you were available and you are hard to get
  with, so I'll adjust.  On the other hand, if the call requires a
  resource booked for a particular time in my time zone, then I'll want
  the meeting to stay where it is by the clock(9am) and will need to
  reschedule with you.

  Since these rule changes tend to be relatively infrequent, a minimum
  implementation MAY USE the UTC format for specifying time and date for
  single instance appointments.  This specifically does not restrict
  client from sending out the more detailed information to specify the
  event time including time zone deltas and labels used to identify the
  time zone, etc. For example, the time zone information could be
  specified by using the recurring event specification below (i.e. a
  single event is a repeating event with one instance).


3.3.2 Recurrence patterns

3.3.2.1 The Recurrence Model

  The recurrence model is based on specifying one or more restrictions,
  similar to a database query, combined with reference date and time
  information. Each restriction, or pattern, is combined with the next
  pattern using the logical AND operation.

  The use of individual properties to describe components of the pattern
  allows for a wide variety of patterns to be specified without


Stenerson                                          [Page 33]



Internet-Draft                                      11/25/96


  specialised parsing or grammar.  The specification for the recurrence
  patterns is discussed in detail below.

  Five properties are used to denote specific days or months. These are:

       DW // DaysOfWeek
       DM // DaysOfMonth
       DY // DaysOfYear
       WY // WeeksOfYear
       MY // MonthsOfYear

  Five properties describe the interval between instances of the
  pattern.

       HI // HourInterval
       DI // DayInterval
       WI // WeekInterval
       MI // MonthInterval
       YI // YearInterval

  Using these properties, it is possible to describe calendar-based
  recurring patterns. (Examples of non-calendar-based patterns include
  Easter and Winter Solstice which are based on lunar patterns.)

  A unique feature of the above properties is that they may be used in
  combination to represent arbitrarily complex recurrence patterns.

  Recurring patterns have ten properties describing the date and time of
  the recurring item. The Start and End single-instance appointment
  properties are not used.

       TStartInst
       TEndInst
       DStart
       DEnd
       DExcept
       DOrigExcept
       WStart
       TZBias
       TZDstBias
       TZStdBias
       TZStdTrans
       TZDstTrans

  The two time-related fields hold the item's start and end time. The
  two date-related fields cover the start and end dates of the recurring
  pattern. It is required to have a start and end date for a pattern;


Stenerson                                          [Page 34]



Internet-Draft                                      11/25/96


  unbounded patterns are not allowed, however no restriction is set on
  the start or end date. The start of week (WStart) property is used to
  indicate what day of the week your calendar starts on. For example, in
  Europe it is common for calendars to start on Monday. The Exception
  Date and Original Exception Date hold exceptions to the recurring
  pattern.

  The following is used to define the reference calendar to be used for
  calculations of the recurrence patterns. The default is Gregorian. No
  additional calendar types are defined at this time. A registration
  procedure for defining new calendar types will need to be created.

       CalTypeID

  A single property is defined to contain the textual description of the
  pattern

       RPDescr

  All of the above property names are defined in detail in Section 3.2.


3.3.2.2 Examples

  The following examples depict recurring patterns using this model.
  Note that the usage of the value=<valuetype> parameter is optional as
  specified in [MIME-DIR]

  Example 1:
  Christmas Day (December 25th) is described as:

     RPDescr: December 25, every year
     MY: 12
     DM: 25
     YI: 1

  Example 2:
  A weeknight television broadcast is described as:

     DW;value=text: Mon, Tue, Wed, Thu, Fri
     WI;value=int: 1
     TStartInst;value=time: 21:00
     TEndInst;value=time: 22:00
     RPDescr: Monday-Friday, every week, 9:00p.m.-10:00 p.m.


  Example 3:


Stenerson                                          [Page 35]



Internet-Draft                                      11/25/96


  Pay-day, the 15th and last day of the month is described as:

     DM;value=int: 15, -1
     MI;value=int: 1
     TStartInst;value=time: 12:00
     TEndInst;value=time: 12:00
     RPDescr: 15th and last day of the month at noon


  Example 4:
  U.S. Presidential Election Day is described as:

     DM;value=int: 2,3,4,5,6,7,8
     DW: Tue
     MY;value=int: 11
     YI;value=int: 4
     RPDescr: First Tuesday after a Monday in November, every four years

  (Since there must be a Monday in November before the election day, Nov
  1 is disqualified.)

  Example 5:
  A monthly recurring monthly appointment for the first Monday of the
  month that starts on 1 Aug 1996 and ends on 1 Aug 1998, includes time
  zone usage.  Time zone is Pacific (UTC-0800).  Daylight Transition
  Date is First Sunday in April at 2:00:00 AM and
  Standard Transition Date is Last Sunday in October at 2:00:00 AM.
  TZStdBias is defaulted to 0


     TStartInst: 8:00
     TEndInst: 09:00
     DStart: 1 Aug 1996
     DEnd: 31 Aug 1998
     DM: 1,2,3,4,5,6,7
     DW: Mon


3.3.3 Change/cancellation semantics

  Often meetings are rescheduled, cancelled or otherwise changed.  When
  a meeting is changed, the attendees of the meeting need to be notified
  of the change, and their calendars need to be updated.

  The key problem in modifying a meeting is that of matching the new
  meeting with the meeting that exists on the calendars of the
  attendees.  This is solved by specifying both an ID for the meeting


Stenerson                                          [Page 36]



Internet-Draft                                      11/25/96


  (created at the original instantiation of the meeting), a version
  number which indicates which change is the most recent when there are
  multiple changes, and a request type which specifies if the change is
  an updated meeting or if it is a cancellation of the meeting.

3.3.3.1 Changing/cancelling an event.

  When the creator of a meeting wants to change all instances of a
  meeting in some way, then the creator sends a completely updated
  meeting request to all the attendees.  The ApptID of the updated
  request contains the ID specified in the original meeting request.  It
  also has an updated ApptVersion property.

  Attendees receiving the updated meeting request look for the previous
  meeting based on the ApptID of the meeting, and replace the existing
  meeting with the new one if the version stamp is newer than the
  existing version stamp.  The ID of the meeting stays the same as the
  original meeting ID so that further changes can be co-ordinated.

  To cancel a single event, a meeting request is sent where the
  RequestType property is "Cancel".  This meeting need only include the
  ApptID property referring to the ID of the original meeting.

3.3.3.2 Changing/cancelling one instance of a recurring event.

  In the case where I wish to change a single instance of a recurring
  event, a complete new appointment is constructed which is the
  exception.  The appointment gets a new ID, and the ApptID property is
  set to the ID of the original meeting request.  A new ApptVersion is
  constructed for the exception.  The DOrigExcept property is used to
  specify which instance of the recurring event this event is an
  exception to.

  To cancel a single event, a meeting request is sent where the
  RequestType property is "Cancel".  This meeting includes: the ApptID
  property which refers to the ID of the original meeting, and the
  DOrigExcept property which refers to which instance of the recurring
  event this cancellation is an exception to.

3.3.3.3 Complex changes

  There will be some changes that will be fairly complex to express in
  terms of changing a meeting.  In these cases, changes should be
  handled by cancelling the meeting and creating one or more new
  meetings.




Stenerson                                          [Page 37]



Internet-Draft                                      11/25/96


3.3.4 Attendees

  Attendees are defined to be the individuals, groups, or resources that
  are invited to an appointment or event. Each attendee must have an
  address that can be used to deliver the appointment request to. There
  are several classes of attendees, including required, optional, owner,
  organizer, and informational (or FYI).

  Attendees for an appointment can be identified and classified in the
  MIME message in a number of ways. The default mechanism uses the
  "To:", "Cc:" and "Bcc:" message header fields as defined in [RFC-822].
  Individuals, groups and resources are all assumed to be valid
  recipients that can be specified in the format of [RFC-822] address
  message header. Attendees in the "To:" header are "required", those in
  the "Cc:" header are "optional", and the "Bcc:" header contains
  "informational" or FYI attendees. The organizer classification is
  assumed to be the appoint request originator ("From:"). The owner
  classification can not be readily specified in the standard [RFC-822]
  header fields, but can be specified using an alternate mechanism as
  described below.

  Optionally, the various classifications of attendees can be specified
  using the following named properties in the "application/calendar"

  Content-Type: AttendReq, AttendOpt, AttendFyi, and AttendOwner. These
  named properties when used, have precedence over the [RFC-822] header
  fields. When a named Attendee property is used, the semantically
  matching RFC-822 header is ignored.  No special treatment is made for
  individuals, groups, or resources; all are assumed to have a valid
  address. These property names are defined in detail in above.


3.4 General Examples

3.4.1 Example: Minimal appointment request

  This demonstrates a minimal appointment request in the
  application/calendar MIME Content-Type. The appointment has a start
  and end date-time.

     To: Franklin W. Dixon <[e-mail]>
     From: Carolyn Keene <[e-mail]>
     Subject: Discuss contract issues
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="request"
     Content-ID: <[e-mail]>



Stenerson                                          [Page 38]



Internet-Draft                                      11/25/96


     ID: <[e-mail]>
     Start;value=d-t: 22 Oct 96 14:00:00 UT
     End;value=d-t: 22 Oct 96 15:00:00 UT


3.4.2 Example: Cancelling a meeting

     To: Larry <[e-mail]>, Curly <[e-mail]>,
      Moe <[e-mail]>
     From: Shemp <[e-mail]>
     Subject: Hey, we need to make some money!
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="request"

     RequestType: Cancel
     ApptID: <[e-mail]>
     Description: Let's just go eat instead.

3.4.3 Example: Recurring appointment request

  This demonstrates a recurring appointment request in the
  application/calendar MIME Content-Type. The recurring pattern
  describes the United States Election Day:

     To: President <[e-mail]>
     From: Vice President <[e-mail]>
     Subject: Don't forget to vote!
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="request"
     Content-ID: <[e-mail]>

     ID: <[e-mail]>
     TStartInst;value=time: 10:00
     TEndInst;value=time: 10:15
     DStart;value=date: 1 Jan 1996
     DEnd;value=date: 1 Jan 2008
     TZID: EST
     TZBias: +05:00
     DM;value=int: 2,3,4,5,6,7,8
     DW: Tue
     MY;value=int: 11
     YI;value=int: 4
     RPDescr: First Tuesday after a Monday in November, every four
      years"



Stenerson                                          [Page 39]



Internet-Draft                                      11/25/96


3.4.4 Recurring appointment with time zone shifts.

  This demonstrates a recurring appointment request in the
  application/calendar MIME Content-Type. The recurring pattern
  describes a monthly recurring monthly appointment for the first Monday
  of the month that starts on 1 Aug 1996 and ends on 1 Aug 1998,
  includes time zone usage.  Time zone is Pacific (UTC-0800).  Daylight
  Transition Date is First Sunday in April at 2:00:00 AM and
  Standard Transition Date is Last Sunday in October at 2:00:00 AM.
  TZStdBias is defaulted to 0

     To: Marketing Team <[e-mail]>
     From: Mr Big <[e-mail]>
     Subject: Monthly Review.
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="request"
     Content-ID: <[e-mail]>

     ID: <[e-mail]>
     TStartInst: 8:00
     TEndInst: 09:00
     DStart: 1 Aug 1996
     DEnd: 1 Aug 1998
     DM: 1,2,3,4,5,6,7
     DW: Mon
     TZID: PST
     TZBias: +08:00
     TZDstBias: -01:00
     TZStdTrans: 27 Oct 1996 02:00
     TZDstTrans: 6 Apr 1997 02:00
     TZStdTrans: 26 Oct 1997 02:00
     TZDstTrans: 5 Apr 1998 02:00

3.4.5 Example: One time exception to recurring meeting

     To: President <[e-mail]>
     From: Vice President <[e-mail]>
     Subject: Don't forget to vote!
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar;
                   profile="request"
     Content-ID: <[e-mail]>

     Start;value=d-t: 7 Nov 1996 15:30 UT
     End;value=d-t: 7 Nov 1996 15:45 UT


Stenerson                                          [Page 40]



Internet-Draft                                      11/25/96


     ApptID: <[e-mail]>
     DOrigExcept;value=date: 5 Nov 1996
     Summary: Rescheduling due to invasion.


3.4.6 Example: Cancelling an instance of a recurring meeting

     To: President <[e-mail]>
     From: Vice President <[e-mail]>
     Subject: Don't forget to vote!
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar;
                   profile="request"
     Content-ID: <[e-mail]>

     ApptID: <[e-mail]>
     Summary: Cancelling due to invasion.
     RequestType: Cancel
     DOrigExcept;value=date: 5 Nov 1996
     Description: There is no time to vote for ourselves this year.


3.4.7 Example: Appointment and message body in the same message.

  This uses the multipart/related Content-Type to add non-textual
  appointment data:

     To: Franklin W. Dixon <[e-mail]>
     From: Carolyn Keene <[e-mail]>
     Subject: Discuss contract issues
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: multipart/related;
             boundary=fence;
             type="application/calendar";
             start="<[e-mail]>"
     Content-ID: <[e-mail]>

     --fence
     Content-Type: application/calendar; profile="request"
     Content-ID: <[e-mail]>

     Start: 22 Oct 96 14:00:00 UT
     End: 22 Oct 96 15:00:00 UT
     Location: Applegate Building, Suite 410
     Map;value=url: "[e-mail]"


Stenerson                                          [Page 41]



Internet-Draft                                      11/25/96



     --fence
     Content-Type: image/jpeg
     Content-ID: "[e-mail]"

     <...image data goes here...>

     --fence--


4. Appointment Responses

4.1 Description

  The Appointment RESPONSE content definition profile.

      Profile name: RESPONSE

      Profile purpose: Indicates schema of RESPONSE items

      Profile special notes: Responses should include as many original
                            appointment request properties as possible.
                            The minimum fields in the response are
                            Response, ApptID, and ApptVersion.  The
                            other fields are included for cases where
                            User Agents do not support automatic
                            correlation of responses.


      Profile intended usage: COMMON


  Example:

  Content-Type: application/calendar; profile="response"


  Profile property names: All defined for appointment request plus:
          ApptResponse


4.2 Properties

4.2.1 ApptResponse

        Name: ApptResponse
        Data type: TEXT
        Purpose: Attendee's response for the Appointment.


Stenerson                                          [Page 42]



Internet-Draft                                      11/25/96


        Encoding: Three values are defined:
                       "Accept": Attendee accepted the
                                 appointment request
                                 and will attend the
                                 appointment.
                       "Decline": Attendee declined the
                                  appointment
                                  request and will not attend
                                  the appointment.
                       "Tentative": Attendee is not sure if he
                                    can attend and has
                                    tentatively accepted the
                                    request, but does not
                                    guarantee he will attend.

                  All values are case insensitive.

        Special notes: Absence of this property indicates that
                       the response is "Accept".
        Required: YES
        Multi-valued: NEVER
        Intended usage: COMMON

4.3 Examples

4.3.1 Example:  Simple appointment response

  This demonstrates an appointment responses.  The minimum fields in the
  response are Response, ApptID, and ApptVersion.  The other fields are
  included for cases where User Agents do not support automatic
  correlation of responses.

     To: Carolyn Keene <[e-mail]>
     From: Franklin W. Dixon <[e-mail]>
     Subject: Discuss contract issues
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="response"

     Response: ACCEPT
     ApptID: <[e-mail]>
     ApptVersion;value=d-t: 21 Oct 96 17:02:34 UT
     Start;value=d-t: 22 Oct 96 17:00:00 UT
     End;value=d-t: 22 Oct 96 18:00:00 UT
     Summary: Let's have a meeting




Stenerson                                          [Page 43]



Internet-Draft                                      11/25/96


4.3.2 Example: decline response to recurring appointment

  This demonstrates an appointment response to a
  recurring appointment or recurring appointment exception
  request:

     To: Carolyn Keene <[e-mail]>
     From: Franklin W. Dixon <[e-mail]>
     Subject: Discuss contract issues
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="response"

     Response: DECLINE
     ApptID: <[e-mail]>
     ApptVersion;value=d-t: 21 Oct 96 17:02:34 PST
     RPDescr: "Every Tuesday"
     Summary: No I can't have a meeting on Tuesdays



4.3.3 Example: Accept response to recurring appointment

  Example demonstrates an appointment response to a
  recurring appointment or recurring appointment exception
  request:

     To: Carolyn Keene <[e-mail]>
     From: Franklin W. Dixon <[e-mail]>
     Subject: Discuss contract issues
     MIME-Version: 1.0
     Message-ID: <[e-mail]>
     Content-Type: application/calendar; profile="response"

     Response: Accept
     ApptVersion;value=d-t: 21 Oct 96 17:02:34 PST
     ApptID: <[e-mail]>
     DOrigExcept;value=date: 28 Oct 1996
     Summary: But I can have a meeting on this Tuesday



5. Acknowledgements

  This document is the result of the collective effort of a large number
  of people on the IETF Calendar Working group mailing list. Although
  any enumeration seems doomed to suffer from egregious omissions, the
  following are among the many contributors to this effort:


Stenerson                                          [Page 44]



Internet-Draft                                      11/25/96



  Darren Shakib
  Alec Dun
  Frank Dawson
  Harald.T.Alvestrand
  Keith Moore
  Pete Resnick
  Ross Finlayson
  Lewis Geer
  Mark Horton
  John C Klensin
  Chris Newman
  Philippe Kahn
  Anik Ganguly
  Ken Shan
  Brian Deen
  Patrik Faltstrom
  Denis BIGORGNE
  Peter O'Leary
  Roger Fajman
  C. Harald Koch
  Hal Howard
  David Boreham
  Ned Freed
  Andrew Shuman
  Nathaniel Borenstein
  Tim Howes
  Andras Salamon
  Bill Bliss
  Theodore Lorek
  Mark Towfiq
  Larry Osterman
  James L. Weiner
  Robert Visnov
  Frederick G.M. Roeber
  William Wyatt
  Mark Handley
  Chuck Grandgent
  William P. Spencer
  Robert Moskowitz
  Steve Carter
  Ian Ferrell


  Format and some descriptions were borrowed from the [MIME-DIR] and
  [MIME-PROP] drafts.



Stenerson                                          [Page 45]



Internet-Draft                                      11/25/96


6. Author's Addresses

  Derik Stenerson

  Microsoft
  One Microsoft Way
  Redmond, WA 98052
  USA
  [e-mail]
  +1.206.936.5522

  Alec Dun
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA  98052
  USA
  [e-mail]
  +1.206.936.4544

   Darren Shakib
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   [e-mail]
   +1.206.936.6405

Appendix A Registration of new profiles

  This section defines procedures by which new profiles are registered
  with the IANA and made available to the Internet community. Note that
  non-IANA profiles may be used by bilateral agreement, provided the
  associated profile names follow the "X-" convention defined above.

  The procedures defined here are designed to allow public comment and
  review of new profiles, while posing only a small impediment to the
  definition of new profiles.

  Registration of a new profile is accomplished by the following steps.

Define the profile

  A profile is defined by completing the following template.

        To: [mailing list TBD]
        Subject: Registration of application/calendar MIME profile XXX

        Profile name:



Stenerson                                          [Page 46]



Internet-Draft                                      11/25/96


        Profile purpose:

        Profile property names:

        Profile special notes (optional):

        Profile Intended usage: (one of COMMON, LIMITED USE or
                                OBSOLETE)

        Property Descriptions: (list of property descriptions in
                                following format)

          Name:

          Data type:

          Purpose:

          Encoding:

          Special notes (optional):

          Required: (one of YES, NO)

          Multi-Valued: (one of ALWAYS, NEVER, SOMETIMES)

          Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

  The explanation of what goes in each field in the template follows.

  Profile name: The name of the profile as it will appear in the
  application/calendar MIME Content-Type "profile" header parameter.

  Profile purpose: The purpose of the profile (e.g., to represent
  information about people, printers, documents, etc.). Give a short but
  clear description.

  Profile property names: The list of property names associated with the
  profile.  This list of names is to be expected but not required in the
  profile.  Other names not mentioned in the profile definition may also
  be present.

  Profile special notes: Any special notes about the profile, how it is
  to be used, etc. This section of the template may also be used to
  define an ordering on the types that appear in the Content-Type, if
  such an ordering is required.



Stenerson                                          [Page 47]



Internet-Draft                                      11/25/96


  Property Descriptions: Precedes the list of property descriptions for
  the profile.  Each property definition starts with the "Name:" tag.

  Name: The name of the property, as it will appear in the body of an
  application/calendar MIME Content-Type "name: value" line to the left
  of the colon ":".

  Data type:  The expected data type for the property.  Possible values
  listed in [MIME-DIR].

  Purpose: The purpose of the property (e.g., to represent a name,postal
  address, IP address, etc.). Give a short but clear description.

  Encoding: The encoding a value of the type must have in the body of an
  application/calendar MIME Content-Type.  This description must be
  precise and must not violate the general encoding rules defined in
  section [MIME-DIR].

  Special notes: Any special notes about the property, how it is to be
  used, etc.

  Required:  YES indicates that the property MUST be present in the
  property list of a item of an item of this type profile.  No indicates
  that this property MAY appear in the property list.

  Multi-Valued:  ALWAYS indicates that the property will expected to be
  multi-valued.  NEVER indicates that the property MUST NOT be multi-
  valued.  SOMETIMES indicates that the property MAY be multi-valued,
  but that most implementations will not make it multi-valued.

  Intended usage: COMMON indicates that most items of this profile will
  include this property.  LIMITED USE indicates that this property will
  rarely be included.  OBSOLETE indicates that use of this property
  SHOULD NOT be used.

Post the profile definition

  The profile description must be posted to the new profile discussion
  list, [mailing list TBD].

Allow a comment period

  Discussion on the new profile must be allowed to take place on the
  list for a minimum of two weeks. Consensus must be reached on the
  profile before submitting the profile for approval




Stenerson                                          [Page 48]



Internet-Draft                                      11/25/96


Submit the profile for approval

  Once the two-week comment period has elapsed, and the proposer is
  convinced consensus has been reached on the profile, the registration
  application should be submitted to the Profile Reviewer for approval.
  The Profile Reviewer is appointed by the Application Area Directors
  and may either accept or reject the profile registration. An accepted
  registration should be passed on by the Profile Reviewer to the IANA
  for inclusion in the official IANA profile registry. The registration
  may be rejected for any of the following reasons. 1) Insufficient
  comment period; 2) Consensus not reached; 3)  Technical deficiencies
  raised on the list or elsewhere have not been addressed. The Profile
  Reviewer's decision to reject a profile may be appealed by the
  proposer to the IESG, or the objections raised can be addressed by the
  proposer and the profile resubmitted.

Appendix B Profile Change Control

  Existing profiles may be changed using the same process by which they
  were registered.

       Define the change

       Post the change

       Allow a comment period

       Submit the profile for approval

  Note that the original author or any other interested party may
  propose a change to an existing profile, but that such changes should
  only be proposed when there are serious omissions or errors in the
  published specification. The Profile Reviewer may object to a change
  if it is not backwards compatible, but is not required to do so.

  Profile definitions can never be deleted from the IANA registry, but
  profiles which are no longer believed to be useful can be declared
  OBSOLETE by a change to their "intended use" field.

References

  [MIME-CSCT], Dawson, Frank, "MIME Calendaring and Scheduling Content
  Type, Internet Draft draft-dawson-csct-00.txt, October 1996

  [MIME-DIR] Howes,T., Smith, M., "A MIME Content-Type for Directory
  Information", Internet-draft-ietf-asid-mime-direct-01.txt, February,
  1996.


Stenerson                                          [Page 49]



Internet-Draft                                      11/25/96



   [MIME-PROP] Shakib, Darren,  "A MIME Content-Type for Tagged Property
   Value Storage", Internet-Draft draft-shakib-mime-prop-00.txt,
   July 1996.

   [MIME-REG] Freed, N.,  Postel,  J.,  "Multipurpose  Internet  Mail
   Extensions (MIME) - Part Four: Registration Procedures", Internet-
   Draft draft-ietf-822ext-mime-reg-02.txt, December 1995.

  [NIST] "Time and Frequency FAQ", National Institute of Standards and
  Technology Time and Frequency Division,  publication on the World Wide
  Web: http://www.boulder.nist.gov


  [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
  Messages", STD 11, RFC 822, August 1982.

  [RFC-1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet
  Mail Extensions) Part One: Mechanisms for Specifying and Describing
  the Format of Internet Message Bodies", RFC 1521, September 1993.

  [RFC-1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
  Part  Two: Message  Header Extensions for Non-ASCII Text", RFC 1522,
  September 1993.

  [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform
  Resource Locators (URL)", RFC 1738, December 1994.

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

  [RFC-1835]
  Deutsch, et al., "Architecture of the WHOIS++ service", RFC 1835,
  August 1995.

  [RFC-1872] Levinson, E., "The MIME Multipart/Related Content-type,"
  RFC 1872, December 1995.




Expires May 30, 1997







Stenerson                                          [Page 50]