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: ietf-types@uninett.no 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 deriks@microsoft.com +1.206.936.5522 Intended usage: COMMON Author/Change controller: Derik Stenerson Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA deriks@microsoft.com +1.206.936.5522 Alec Dun Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA alecdu@microsoft.com +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: <id2@bogus.com> 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 <larry@wiseguy.com>, Curly <curly@wiseguy.com>, Moe <moe@wiseguy.com> From: Shemp <shemp@wiseguy.com > Subject: Hey, we need to make some money! MIME-Version: 1.0 Message-ID: <id1@wizeguy.com> 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: <uniquefoo@wizeguy.com> 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 <franklind@bogus.com> From: Carolyn Keene <carolynk@bogus.com> Subject: Discuss contract issues MIME-Version: 1.0 Message-ID: <id1@bogus.com> Content-Type: application/calendar; profile="request" Content-ID: <id2@bogus.com> Stenerson [Page 38]
Internet-Draft 11/25/96 ID: <foo@bogus.com> 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 <larry@wiseguy.com>, Curly <curly@wiseguy.com>, Moe <moe@wiseguy.com> From: Shemp <shemp@wiseguy.com> Subject: Hey, we need to make some money! MIME-Version: 1.0 Message-ID: <id1@wizeguy.com> Content-Type: application/calendar; profile="request" RequestType: Cancel ApptID: <uniquefoo@wizeguy.com> 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 <president@whitehouse.gov> From: Vice President <vice.president@whitehouse.gov> Subject: Don't forget to vote! MIME-Version: 1.0 Message-ID: <id1@whitehouse.gov> Content-Type: application/calendar; profile="request" Content-ID: <id2@whitehouse.gov> ID: <foo@bogus.com> 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 <marketing@bigbiz.com> From: Mr Big <mr.big@bigbiz.com> Subject: Monthly Review. MIME-Version: 1.0 Message-ID: <id1@bigbiz.com> Content-Type: application/calendar; profile="request" Content-ID: <id2@bigbiz.com> ID: <foomarket@bigbiz.com> 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 <president@whitehouse.gov> From: Vice President <vice.president@whitehouse.gov> Subject: Don't forget to vote! MIME-Version: 1.0 Message-ID: <id1@whitehouse.gov> Content-Type: application/calendar; profile="request" Content-ID: <id2@whitehouse.gov> 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: <foo@bogus.com> DOrigExcept;value=date: 5 Nov 1996 Summary: Rescheduling due to invasion. 3.4.6 Example: Cancelling an instance of a recurring meeting To: President <president@whitehouse.gov> From: Vice President <vice.president@whitehouse.gov> Subject: Don't forget to vote! MIME-Version: 1.0 Message-ID: <id1@whitehouse.gov> Content-Type: application/calendar; profile="request" Content-ID: <id2@whitehouse.gov> ApptID: <foo@bogus.com> 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 <franklind@sample.com> From: Carolyn Keene <carolynk@sample.com> Subject: Discuss contract issues MIME-Version: 1.0 Message-ID: <id1@sample.com> Content-Type: multipart/related; boundary=fence; type="application/calendar"; start="<id4@sample.com>" Content-ID: <id3@sample.com> --fence Content-Type: application/calendar; profile="request" Content-ID: <id4@sample.com> Start: 22 Oct 96 14:00:00 UT End: 22 Oct 96 15:00:00 UT Location: Applegate Building, Suite 410 Map;value=url: "id5@sample.com" Stenerson [Page 41]
Internet-Draft 11/25/96 --fence Content-Type: image/jpeg Content-ID: "id5@sample.com" <...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 <carolynk@bogus.com> From: Franklin W. Dixon <franklind@bogus.com> Subject: Discuss contract issues MIME-Version: 1.0 Message-ID: <id1@bogus.com> Content-Type: application/calendar; profile="response" Response: ACCEPT ApptID: <foo@bogus.com> 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 <carolynk@bogus.com> From: Franklin W. Dixon <franklind@bogus.com> Subject: Discuss contract issues MIME-Version: 1.0 Message-ID: <id1@bogus.com> Content-Type: application/calendar; profile="response" Response: DECLINE ApptID: <foo@bogus.com> 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 <carolynk@bogus.com> From: Franklin W. Dixon <franklind@bogus.com> Subject: Discuss contract issues MIME-Version: 1.0 Message-ID: <id1@bogus.com> Content-Type: application/calendar; profile="response" Response: Accept ApptVersion;value=d-t: 21 Oct 96 17:02:34 PST ApptID: <blah@bogus.com> 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 deriks@microsoft.com +1.206.936.5522 Alec Dun Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA alecdu@microsoft.com +1.206.936.4544 Darren Shakib Microsoft One Microsoft Way Redmond, WA 98052 darrens@microsoft.com +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]
