Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-calsch-ical-01.txt < prev next >

Wrap

Text File | 1997-03-26 | 165KB | 4,527 lines

Network Working Group Frank Dawson, Lotus Internet Draft Derik Stenerson, Microsoft <ietf-calsch-ical-01.txt> March 26, 1997 Expires September 1997 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Abstract There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This document has been defined to provide the a definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is "TEXT/CALENDAR". This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event and to-do information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems or using HTTP. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. Dawson/Stenerson 1 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 This document is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information. In order to avoid confusion with this referenced work, this document is to be known as the iCalendar specification. This document also includes the format for defining content type profiles. A content type profile is a document that defines a set of usage constraints for the iCalendar Object. For example, a profile might be defined to specify how the iCalendar Object can be used to provide for a set of interpersonal scheduling messages. Such a profile might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do calendar component. Table of Contents 1. Introduction........................................................4 2. Basic Grammar and Conventions.......................................5 3. Definitions.........................................................5 3.1 Alarm ............................................................6 3.2 Busy Time ........................................................6 3.3 Calendar Component ...............................................6 3.4 Calendar Date ....................................................6 3.5 Calendar Object ..................................................6 3.6 Calendar Properties ..............................................6 3.7 Calendar Scale ...................................................6 3.8 Component Properties .............................................6 3.9 Coordinate Universal Time (UTC) ..................................7 3.10 Daylight Saving Time (DST) ......................................7 3.11 Event ...........................................................7 3.12 Free Time .......................................................7 3.13 Gregorian Calendar ..............................................7 3.14 Journal .........................................................7 3.15 Local Time ......................................................7 3.16 Period ..........................................................8 3.17 Recurrence Rule .................................................8 3.18 Reminder ........................................................8 3.19 Repeating Event or To-do ........................................8 3.20 Standard Time ...................................................8 3.21 Time Zone .......................................................8 3.22 To-do ...........................................................9 4. TEXT/CALENDAR Registration Information..............................9 5. iCalendar Object Specification.....................................11 5.1 Syntax Considerations ...........................................11 5.1.1 Content Lines ................................................12 5.1.2 List and Field Separators ....................................13 5.1.3 Grouping .....................................................14 5.1.4 Multiple Values ..............................................14 5.1.5 Character Set ................................................15 5.1.6 Language .....................................................15 Dawson/Stenerson 2 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.1.7 Content Encoding .............................................15 5.1.8 Binary Content ...............................................15 5.1.9 Recurrence Set ...............................................15 5.1.10 Data Types ..................................................16 5.1.10.1 URL .....................................................16 5.1.10.2 Text ....................................................16 5.1.10.3 Date ....................................................16 5.1.10.4 Time ....................................................17 5.1.10.5 Date-Time ...............................................18 5.1.10.6 Duration ................................................18 5.1.10.7 Period of Time ..........................................19 5.1.10.8 Boolean .................................................19 5.1.10.9 Integer .................................................20 5.1.10.10 Float ..................................................20 5.1.10.11 RFC 822 Address ........................................20 5.1.10.12 UTC Offset .............................................21 5.2 iCalendar Object ................................................21 5.3 Property ........................................................22 5.4 Calendar Components .............................................22 5.4.1 Event Component ..............................................22 5.4.2 To-do Component ..............................................23 5.4.3 Journal Component ............................................24 5.4.4 Free/Busy Component ..........................................24 5.4.5 Alarm Component ..............................................25 5.4.6 Timezone Component ...........................................26 5.4.7 Calendar Properties ..........................................28 5.4.7.1 Calendar Scale ...........................................28 5.4.7.2 Geographic Position ......................................29 5.4.7.3 Product Identifier .......................................29 5.4.7.4 Profile ..................................................30 5.4.7.5 Profile Version ..........................................30 5.4.7.6 Source ...................................................31 5.4.7.7 Source Name ..............................................31 5.4.7.8 Version ..................................................31 5.5 Component Properties ............................................32 5.5.1.1 Attachment ...............................................32 5.5.1.2 Attendee .................................................32 5.5.1.3 Categories ...............................................34 5.5.1.4 Classification ...........................................35 5.5.1.5 Date/Time Created ........................................35 5.5.1.6 Date/Time Completed ......................................36 5.5.1.7 Daylight .................................................36 5.5.1.8 Description ..............................................36 5.5.1.9 Due Date/Time ............................................37 5.5.1.10 Duration ................................................37 5.5.1.11 Start Date/Time .........................................38 5.5.1.12 End Date/Time ...........................................38 5.5.1.13 Exception Date/Times ....................................39 5.5.1.14 Exception Rule ..........................................39 5.5.1.15 Free/Busy Time ..........................................40 5.5.1.16 Last Modified ...........................................41 5.5.1.17 Location ................................................41 5.5.1.18 Priority ................................................42 5.5.1.19 Related To ..............................................42 Dawson/Stenerson 3 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.5.1.20 Recurrence Date/Times ...................................43 5.5.1.21 Recurrence Rule .........................................44 5.5.1.22 Resources ...............................................49 5.5.1.23 Response Sequence Number ................................50 5.5.1.24 Sequence Number .........................................50 5.5.1.25 Status ..................................................51 5.5.1.26 Summary .................................................51 5.5.1.27 Time Transparency .......................................52 5.5.1.28 Time Zone Name ..........................................52 5.5.1.29 Time Zone Offset ........................................53 5.5.1.30 Time Zone Transition Time ...............................53 5.5.1.31 Uniform Resource Locator ................................53 5.5.1.32 Unique Identifier .......................................54 5.5.1.33 Non-standard Properties .................................54 5.6 Complete Format Definition ......................................55 6. Registration of Content Type Profiles..............................65 6.1 Define the profile ..............................................65 6.2 Post the profile definition .....................................66 6.3 Allow a comment period ..........................................66 6.4 Submit the profile for approval .................................66 6.5 Profile Change Control ..........................................66 6.6 Registration of New Properties ..................................67 6.6.1 Define the property ..........................................67 6.6.2 Post the Property definition .................................68 6.6.3 Allow a comment period .......................................68 6.6.4 Submit the property for approval .............................68 6.7 Property Change Control .........................................68 7. File extension.....................................................69 8. Macintosh File Type Code...........................................69 9. References.........................................................69 10. Acknowledgments...................................................70 11. Author's Address..................................................70 12. iCalendar Object Examples.........................................71 1. Introduction The use of calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. However, the longer term growth of calendaring and scheduling, is currently limited by the lack of Internet standards for the message content types that are central to these groupware applications. This specification is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications. This specification defines a MIME content type for exchanging electronic calendaring and scheduling information. The Internet Calendaring and Scheduling Core Object Specification, or iCalendar, allows for the capture and exchange of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager or a Group Scheduling product. The format is suitable as an exchange format between applications or systems. The format is defined in terms of a MIME content type. This Dawson/Stenerson 4 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 will enable the object to be exchanged using several transports, including but not limited to SMTP, HTTP, a file system, desktop interactive protocols such as the use of a memory-based clipboard or drag/drop interactions, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport such as infrared might also be used. The specification also provides for the definition of usage profiles that will map this content type to a set of messages for supporting calendaring and scheduling operations such as requesting, replying to, modifying, and canceling meetings or appointments, to-dos and journal entries. The usage profiles can be used to define other calendaring and scheduling operations such a requesting for and replying with free/busy time data. The specification also includes a formal grammar for the content type to aid in the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the specification. 2. Basic Grammar and Conventions This document makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this document is the augmented BNF notation of [RFC 822]. Readers intending on implementing this format defined in this document should be familiar with this notation in order to properly interpret the specifications of this document. All numeric and hexadecimal values used in this document are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case- insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information that is not essential to the building of a conformant implementation of the specifications of this document. The information is provided to highlight a particular feature or characteristic of the specifications. The format for the iCalendar Object is based on the syntax of the [MIME DIR] content type. While the iCalendar Object is not a profile of the [MIME DIR] content type, it does reuse a number of the elements from the [MIME DIR] specification. 3. Definitions Date and time, as well as, calendaring and scheduling terminology are used in every day conversations. However, there are precise definitions of many of these terms that are used by this memo. Dawson/Stenerson 5 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 3.1 Alarm Also called a reminder. An activity that is an asynchronous mechanism for providing feedback for a pending or past event or to-do. 3.2 Busy Time A period of time of time on a calendar where there is already scheduled one or more events or that is otherwise not available for scheduling. 3.3 Calendar Component One of a number of entities that may be found within a calendar object. In particular, a calendar may be composed of calendar properties and event, to-do, journal, free/busy, time zone or alarm calendar components. Calendar components are identified by unique delimiters within a calendar object. Calendar components provide an organized collection of component properties. 3.4 Calendar Date A particular day of a calendar year identified by its position within the year. 3.5 Calendar Object An entity consisting of an organized collection of calendar properties and calendar components. The calendar object is identified by unique delimiters. 3.6 Calendar Properties Attributes that apply to the calendar object as a whole. For example, the iCalendar version used to format the calendar object, an identifier of the product that created the calendar object, the calendar scale used to represent the calendar information and time zone information. 3.7 Calendar Scale The particular type of calendar in general use. For example, Gregorian, Buddhist Era, Japanese Emperor Era, Chinese Lunar, Islamic, and Jewish Calendars. 3.8 Component Properties Attributes that can only appear within one or more calendar components. For example, the due date can only appear within a to-do calendar component. The start date and time applies to both the event and the to-do component. Dawson/Stenerson 6 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 3.9 Coordinate Universal Time (UTC) The time scale maintained by the Bureau International de l'Heure (International Time Bureau) that forms the basis of a coordinated dissemination of standard frequencies and time signals. UTC is often incorrectly referred to as GMT. 3.10 Daylight Saving Time (DST) An adjustment to local to accommodate annual changes in the number of daylight hours. DST is also known as Advanced Time, Summer Time, or Legal Time. Daylight saving time adjustments in the southern hemisphere are opposite to those in the northern hemisphere. 3.11 Event A calendar component that defines a scheduled activity, minimally specified by a start and end calendar date and time of day and a description. 3.12 Free Time A period of time available on a calendar. 3.13 Gregorian Calendar A calendar scale in general use beginning in 1582. It was introduced to correct an error in the Julian Calendar scale. The Gregorian Calendar scale is based on a solar calendar consisting of common years made up of 365 days and leap years made up of 366 days; both divided into 12 sequential months. Note: Initially, this memo addresses specification of calendar information in terms of the Gregorian calendar scale. 3.14 Journal A calendar component that defines a collection of information intended for human presentation and is minimally specified by a calendar date and one or more descriptions. 3.15 Local Time The clock time in public use in a locale. Local time is often referenced by the customary name for the time zone in which it is located. The relationship between local time and UTC is based on the offset(s) that are in use for a particular time zone. In general, the formula is as follows: local time = UTC + (offset) Dawson/Stenerson 7 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 3.16 Period A duration of time, specified as either a defined length of time or by its beginning and end points. 3.17 Recurrence Rule A notation used to represent repeating occurrences, or the exceptions to such a repetition of an event or a to-do. The recurrence rule can also be used in the specification of a time zone description. This document defines a particular notation used in recurrence rules within this specification. 3.18 Reminder See Alarm. 3.19 Repeating Event or To-do An event or to-do that repeats for one or more additional occurrences. The recurrence may be defined with discrete dates and times and/or with a recurrence rule. 3.20 Standard Time Introduced by Sir Sanford Fleming and others around 1870, standard time is a scheme for dividing the world into zones where the same time would be kept. The original proposal was to divide the world into 24 zones, each zone having a width of 15 degrees of longitude. The center zone was originally the meridian passing through Greenwich, England, called Greenwich Mean Time (GMT). The time in the zones was decremented by one hour per zone going westwards and was incremented by one hour per zone going eastwards from GMT. Changes have been made to the original proposal to accommodate political boundaries. In addition, some countries and regions specify 30 or 45 minute offsets, rather than the full 60 minute offset. Standard time is also known as Winter Time in some regions. GMT and UTC are generally equivalent. However, by international agreement, the GMT term is discouraged in favor of the term UTC for all general time keeping. 3.21 Time Zone The particular time zone that time in a particular location is expressed in. A time zone is unambiguously defined by the set of time measurement rules determined by the governing body for the given location. These rules describe at a minimum the base offset from UTC, often referred to as the Standard Time offset. Optionally, if Daylight Savings Time is observed, the rules will specify the Daylight Savings Time offset and either a set of rules describing the transition to and from Daylight Savings Time or absolute dates describing the movement in and out of Daylight Savings Time. It is important to note that these rules are not static. Time zones may Dawson/Stenerson 8 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 also have a local customary name. However, not all time zones have a special name for their time. The customary names for time zones are often abbreviated. However, not all time zone abbreviations are unique. For example, AST may mean Atlantic Standard Time, Alaska Standard Time, and even Aleutian Standard Time. Each of these are different offsets from UTC. Nevertheless, customary names for time zones are in use in various parts of the world. 3.22 To-do A calendar component that defines an action item and is minimally specified by an effective calendar date and time of day, a due calendar date and time of day, a priority and a description. 4. TEXT/CALENDAR Registration Information The Calendaring and Scheduling Core Object Specification is intended for use as a MIME content type. However, the implementation of the specification is in no way limited solely as a MIME content type. The following text is intended to register this specification as the MIME content type "text/calendar". To: ietf-types@uninett.no Subject: Registration of MIME content type text/calendar. MIME media type name: text MIME subtype name: calendar Required parameters: profile The "profile" parameter is used to convey the scheduling usage to which the calendaring and scheduling information pertains. It also is an identifier for the set of properties that the iCalendar Object will consist of. The parameter is intended to be used as a guide to applications interpreting the information contained within the body part. It should NOT be used to exclude or require particular pieces of information unless the identified profile definition specifically calls for this behavior. Unless specifically forbidden by a particular profile definition, a text/calendar content type may contain any set of properties permitted by the Calendaring and Scheduling Core Object Specification. The value for the "profile" parameter is defined as follows: profile = component "-" usage component = "EVENT" / "event" / "TODO" / "todo" / "JOURNAL" / "journal" / "FREEBUSY" / "freebusy" / x-token / iana-comp Dawson/Stenerson 9 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 usage = "REQUEST" / "request" / "REPLY" / "reply" / "CANCEL" / "cancel" / "x-token / iana-usage x-token = <The two characters "X-" or "x-" followed, with no intervening white space, by any atom, where atom is from section 3.3 of [RFC 822]> iana-comp = <A publicly defined extension component, registered with IANA, as specified by this document> iana-usage = <A publicly defined extension usage, registered with IANA, as specified by this document> Optional parameters: charset The "charset" parameter is defined in [RFC 2046] for other body parts. It is used to identify the default character set used within the body part. Note that alternate character sets can be specified on a per-value basis using the "charset" property parameter defined in [MIME DIR]. Optional content header fields: Any header fields defined by [RFC 2045]. Encoding considerations: This MIME content type does not introduce any new encoding types beyond those defined in [RFC 2045]. Note that each property in the content entity may also have an inline encoding for the body part as a whole (i.e., inline encoding are performed first, then Content-Transfer-Encoding is applied to the entire body part). This means that content values may end up encoded twice. Security considerations: The calendaring and scheduling information based on this MIME content type may include references to Uniform Resource Locators that may be programmed resources. In addition, this information may contain direct references to executable programs intended to be used as procedure-based alarms for an event or to-do. Implementers and users of this specification should be aware of the network security implications of accepting and parsing such information. Interoperability considerations: This MIME content type is intended to provide interoperability between calendaring and scheduling products. It is heavily based on the earlier [VCAL] industry specification. Intended Usage: COMMON Published specification: This remainder of this document. Author/Change controllers: Dawson/Stenerson 10 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Frank Dawson 6544 Battleford Drive Raleigh, NC 27613-3502 919-676-9515 (Telephone) 919-676-9564 (Facsimile) fdawson@earthlink.net (Internet Mail) Derik Stenerson One Microsoft Way Redmond, WA 98052-6399 206-936-5522 (Telephone) 206-936-7329 (Facsimile) deriks@microsoft.com (Internet Mail) 5. iCalendar Object Specification The following sections define the details of a Calendaring and Scheduling Core Object Specification. This information is intended to be an integral part of the MIME content type registration. In addition, this information may be used independent of such content registration. In particular, this specification has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. 5.1 Syntax Considerations The content information associated with an iCalendar Object is formatted using a syntax similar to that defined by [MIME DIR]. That is, the content information consists of one or more CRLF-separated lines in the following format: contentline = [group "."] name [";" paramlist] ":" value CRLF ;Folding permitted on content lines. group = atom ;As defined in [RFC 822] name = x-name / iana-name ;An iCalendar attribute/property x-name = <The two characters "X-" or "x-" followed, with no intervening white space, by any atom> iana-name = <A publicly defined name, registered with IANA> paramlist = parameter / paramlist ";" parameter parameter = encodingparm / valuetypeparm ;If not present => inline value / charsetparm / languageparm / [parmtype "="] parmvalues encodingparm = "encoding" "=" encodetype Dawson/Stenerson 11 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 encodetype = "8bit" ;From [RFC 2045] / "7bit" ;From [RFC 2045] / "base64" ;From [RFC 2045] / "quoted-printable" ;From [RFC 2045] valuetypeparm = "value" "=" valuetype valuetype = "url" / "text" / "date" / "time" / "date-time" / "period" / "duration" / "boolean" / "integer" / "float" / "rfc822-address" / "utc-offset" / x-token / iana-value iana-value = <A publicly defined extension value type, registered with IANA, as specified by this document> charsetparm = "charset" "=" charset ;As defined in [RFC 2047] languageparm = "language" "=" language ;As defined in [RFC 1766] parmtype = x-token / iana-ptype iana-ptype = <A publicly defined extension parameter type, registered with IANA, as specified by this document> parmvalues = parmvalue / parmvalues "," parmvalue parmvalue = x-name / iana-pvalue iana-pvalue = <A publicly defined extension parameter value, registered with IANA, as specified by this document> value = url / text / date / time/ date-time / period / / duration / boolean / integer / float / rfc822-address / utc-offset / x-token / iana-value iana-value = <A publicly defined property value data type, registered with IANA, as defined in this document> 5.1.1 Content Lines Individual lines within the iCalendar Object are delimited by the [RFC 822] line break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII decimal 10). Line should not be longer than 76 characters, excluding the line break. Dawson/Stenerson 12 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Long lines of text can be split into a multiple-line representation using a line "folding" technique. That is, wherever a line split is desired a CRLF immediately followed by one LWSP-char must instead be inserted. For example the line: DESCRIPTION:This is a long description that exists on a long line. Can be represented as: DESCRIPTION:This is a long description that exists on a long line. The process of moving from this folded multiple-line representation to its single line representation is called "unfolding". Unfolding is accomplished by removing the CRLF immediately followed by a LWSP- char. An intentional formatted text line break in a property value must also be specified by a (RFC 822) line break, which is a CRLF sequence. However, since the CRLF sequence is used to delimit a line, property values with imbedded formatted line breaks (i.e., hard line breaks) must be encoded using an alternate encoding of either quoted- printable or base64, as defined in [RFC 2045]. The quoted-printable encoding of the multiple lines of formatted text are separated with a quoted-printable CRLF sequence of "=0D" followed by "=0A" followed by a Quoted-Printable soft line break sequence of "=". Quoted-printable lines of text must also be limited to less than 76 characters. The 76 characters does not include the CRLF [RFC 822] line break sequence. For example a multiple line DESCRIPTION value of: Project XYZ Final Review Conference Room - 3B Come Prepared. Would be represented in a Quoted-Printable encoding as: DESCRIPTION; QUOTED-PRINTABLE:Project XYZ Final Review=0D=0A= Conference Room - 3B=0D=0A= Come Prepared. White space characters (i.e., HTAB and SPACE characters, ASCII decimal 9 and 32) to the left of a "value" may freely surround any symbol. This means that if a "value" begins with a white space character, it must be encoded using either the base64 or quoted- printable encoding methods. 5.1.2 List and Field Separators Where a property parameter value consists of a list of values, each value must be separated by a COMMA character (ASCII decimal 44). A Dawson/Stenerson 13 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 COMMA character in a property parameter value must be escaped with a BACKSLASH character (ASCII decimal 92). Structured property values must have their components separated by a SEMICOLON character (ASCII decimal 59). In addition, lists of property parameters must be separated by a SEMICOLON character (ASCII decimal 59). A SEMICOLON character in a property value or property parameter value must be escaped with a BACKSLASH character (ASCII decimal 92). For example, in the following properties a SEMICOLON is used to separate property parameters and property value fields. A COMMA is used to separate values. ATTENDEE;RSVP=YES;ROLE=ATTENDEE:"J.Smith" <jsmith@host.com) RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 5.1.3 Grouping The group construct is used to group related properties together. The group name is a syntactic convention used to indicate that all property names prefaced with the same group name should be processed together when displayed by an application. It has no other significance. Implementations that do not understand or support grouping may simply strip off any text before the PERIOD character (ASCII decimal 46) and present the property and value as normal. The following provides an example of property grouping. The first start, end and busy time are grouped together with a label "GROUPA". The second start, end and busy time are grouped together with a label "GROUPB". GROUPA.DTSTART:19970101T000000-0500 GROUPA.DTEND:19970101T235959-0500 GROUPA.BUSYTIME;VALUE=PERIOD-START:19970101T000000-0500/PT8H30M, 19970101T100000-0500/PT2H,19970101T150000-0500/PT20H59M59S GROUPB.DTSTART:19970102T000000-0500 GROUPB.DTEND:19970102T235959-0500 GROUPB.BUSYTIME;VALUE=PERIOD-START=19970102T000000-5000/PT10H, 19970102T130000-0500/PT6H 5.1.4 Multiple Values Each attribute or property defined in the iCalendar Object may have multiple values, if allowed in the definition of the specific property. The general rule for encoding multi-valued items is to simply create a new content line for each value; including the property name. However, it should be noted that some properties support encoding multiple values in a single property by separating the values with a COMMA (ASCII decimal 44). Dawson/Stenerson 14 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.1.5 Character Set The "charset" property parameter should be used to identify character sets other than "US-ASCII". The "charset" property parameter can be used to change the default character set on a per-value basis. The value of the charset property parameter is any IANA registered character set. Note: For transport in a MIME entity, the "charset" Content-Type parameter may be used to set the default character set for the entire body part. 5.1.6 Language The "language" property parameter should be used to identify data in alternate languages. The default language is "us-EN". The value of the language property parameter is that defined in [RFC 1766]. Note: For transport in a MIME entity, the Content-Language header field may be used to set the default language for the entire body part. 5.1.7 Content Encoding The "encoding property parameter should be used to specify an alternate encoding for a value. If the value contains a <CR> character (ASCII decimal 10) or <LF> character (ASCII decimal 13), it must be encoded using either base64 or quoted-printable, since <CR><LF> is used to separate lines in the iCalendar Object itself. 5.1.8 Binary Content There is no support for inline encoding of binary information in an iCalendar Object. Binary information is associated with the iCalendar Object through the use of a uniform resource locator (URL) reference to the binary information. 5.1.9 Recurrence Set Recurring events and to-dos are supported by this specification. The recurrence within the iCalendar Object may be specified as either a list of discrete date and time values or as a recurrence rule. The full recurrence set is generated by considering the initial DTSTART along with the RRULE, RDATE, EXDATE and EXRULE properties contained within the iCalendar object. Multiple instances of the RRULE and EXRULE properties may also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date-times generated by any of the specified RRULE and RDATE properties, and excluding any start date and times which fall within the union of start date and times generated by any specified EXRULE and EXDATE properties. This implies that start date and times within exclusion related properties (i.e., EXDATE and EXRULE) take precedence over those specified by inclusion properties (i.e., RDATE and RRULE). Dawson/Stenerson 15 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 The recurrence rule used in the iCalendar Object is defined in the RRULE component property. 5.1.10 Data Types The "value" property parameter is an optional property parameter. It is used to identify the data type and format of the property value. The following data types are used by the iCalendar Object. 5.1.10.1 URL The "url" data type is used to identify values that contain a uniform resource locator (URL) type of reference to the property value. This data type might be used to reference binary information, for values that are large, or otherwise undesirable to include directly in the iCalendar Object. The data type is defined by the following notation: url = <As defined by [RFC 1738]> Any IANA registered URL type may be used. These include, but are not limited to, those for FTP and HTTP protocols, file access, content identifier and message identifier. For example, the following is an URL for a local file: file:///my-report.txt 5.1.10.2 Text The "text" data type is used to identify values that contain human readable text. The character set and language in which the text is represented is controlled by the charset and language property parameters. The data type is defined by the following notation: CHAR = <Any character in the selected character set> text = <Any CHAR, including bare CR & bare LF but not including CRLF> 5.1.10.3 Date The "date" data type is used to identify values that contain a calendar date. The format is expressed as the [ISO 8601] complete representation, basic format for a calendar date. The text format specifies a four-digit year, two-digit month, and two-digit day of the month. There are no separator characters between the year, month and day component text. The data type is defined by the following notation: DIGIT =<any ASCII decimal digit> ;0-9 date-fullyear = 4DIGIT date-month = 2DIGIT ;01-12 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 Dawson/Stenerson 16 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 ;based on month/year full-date = date-fullyear date-month date-mday date = fulldate *["," fulldate] For example, the following represents July 14, 1997: 19970714 5.1.10.4 Time The "time" data type is used to identify values that contain a time of day. The format is expressed as the [ISO 8601] complete representation, basic format for a time of day. The text format consists of a two-digit 24-hour of the day, two-digit minute in the hour, and two-digit seconds in the minute. If seconds of the minute are not supported by an implementation, then a value of "00" should be specified for the seconds component. Fractions of an hour, minute or second are not supported by this format. This format is used to represent local time, local time with UTC offset and UTC time. UTC time is identified by a LATIN CAPITAL LETTER Z suffix character (ASCII decimal 90), the UTC designator, appended to the time. The local time with UTC offset is expressed as a local time, suffixed with the signed offset from UTC. The UTC offset is express as the 2- digit hours and 2-digit minutes difference from UTC. It is expressed as positive, with an optional leading PLUS SIGN character (ASCII decimal 43), if the local time is ahead of UTC. It is expressed as a negative, with a leading HYPEN-MINUS character (ASCII decimal 45), if the local time is behind UTC. Local time has neither the UTC designator nor the UTC offset suffix text. The data type is defined by the following notation: DIGIT =<any ASCII decimal digit> ;0-9 time-hour = 2DIGIT ;00-24 time-minute = 2DIGIT ;00-60 time-second = 2DIGIT ;00-59 time-numzone = ("+" / "-") time-hour time-minute time-zone = "Z" / time-numzone full-time = time-hour time-minute time-second [time-zone] time = fulltime *["," fulltime] For example, the following represents 8:30 AM in New York, five hours behind UTC, in local time and local time with UTC offset. In addition, 1:30 PM in UTC is illustrated: 083000 083000-0500 133000Z There are cases when a floating time is intended within a property value. For example, an event may be defined that indicates that an Dawson/Stenerson 17 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 individual will be busy from 11:00 AM to 1:00 PM every day. In these cases, a local time may be specified. The recipient of an iCalendar Object with a property value consisting of a local time, without any relative time zone information, should interpret the value as being fixed to the recipient's locale and time zone. In most cases, a fixed time is desired. To properly communicate a fixed time in a property value, either UTC, local time with UTC offset, or local time with a time zone calendar component must be specified. 5.1.10.5 Date-Time The "date-time" data type is used to identify values that contain a precise calendar date and time of day. The format is expressed as the [ISO 8601] complete representation, basic format for a calendar date and time of day. The text format is a concatenation of the "date", followed by the LATIN CAPITAL LETTER T character (ASCII decimal 84) time designator, followed by the "time" format defined above. The data type is defined by the following notation: date-time = date "T" time ;As specified above in date and time The following represents July 14, 1997, at 1:30 PM in UTC and the equivalent time in New York (five hours behind UTC), expressed as a local time and local time with UTC offset: 19970714T133000Z 19970714T083000 19970714T083000-0500 5.1.10.6 Duration The "duration" data type is used to identify properties that contain a duration of time. The format is expressed as the [ISO 8601] basic format for the duration of time. The format can represent durations in terms of years, months, days, hours, minutes, and seconds. The data type is defined by the following notation: DIGIT =<any ASCII decimal digit> ;0-9 dur-second = 1*DIGIT "S" dur-minute = 1*DIGIT "M" [dur-second] dur-hour = 1*DIGIT "H" [dur-minute] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1*DIGIT "W" dur-day = 1*DIGIT "D" dur-month = 1*DIGIT "M" [dur-day] dur-year = 1*DIGIT "Y" [dur-month] dur-date = (dur-day / dur-month / dur-year) [dur-time] duration = "P" (dur-date / dur-time / dur-week) For example, a duration of 10 years, 3 months, 15 days, 5 hours, 30 minutes and 20 seconds would be: Dawson/Stenerson 18 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 P10Y3M15DT5H30M20S 5.1.10.7 Period of Time The "period" data type is used to identify values that contain a precise period of time. There are two forms of a period of time. A period of time may be identified by it start and its end. This format is expressed as the [ISO 8601] complete representation, basic format for "date-time" start of the period, followed by a SOLIDUS character (ASCII decimal 47), followed by the "date-time" of the end of the period. For example, the period starting at 10 AM in Seattle (eight hours behind UTC) on January 1, 1997 and ending at 11 PM in Seattle on January 1, 1997 would be: 19970101T100000-0800/19970101T230000-0800 A period of time may also be defined by a start and a duration of time. The format is expressed as the [ISO 8601] complete representation, basic format for the "date-time" start of the period, followed by a SOLIDUS character (ASCII decimal 47), followed by the [ISO 8601] basic format for "duration" of the period. For example, the period start at 10 AM in Seattle (eight hours behind UTC) on January 1, 1997 and lasting 5 hours and 30 minutes would be: 19970101T100000-0800/P5H30M The data type is defined by the following notation: period-explicit = date-time "/" date-time ;ISO 8601 complete representation basic format for a period of time ;consisting of a start and end. The start must be before the end. period-start = date-time "/" duration ;ISO 8601 complete representation basic format for a period of time ;consisting of a start and duration of time. period = period-explicit / period-start 5.1.10.8 Boolean The "boolean" data type is used to identify properties that contain either a "true" or a "false" boolean value. These values are case insensitive. The data type is defined by the following notation: boolean = "TRUE" / "FALSE" For example, any of the following are equivalent: TRUE true TrUe Dawson/Stenerson 19 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.1.10.9 Integer The "integer" data type is used to identify properties that contain a signed integer value. The valid range for "integer" is -2147483648 to 2147483647. If the sign is not specified, then the value is assumed to be positive. If the property permits, multiple "integer" values may be specified using a COMMA character (ASCII decimal 44) separator character. The data type is defined by the following notation: DIGIT =<any ASCII decimal digit> ;0-9 integer = ["+" / "-"] *DIGIT For example: 1234567890 -1234567890 +1234567890 432109876 5.1.10.10 Float The "float" data type is used to identify properties that contain a real value number value. If the property permits, multiple "float" values may be specified using a COMMA character (ASCII decimal 44) separator character. The data type is defined by the following notation: DIGIT =<any ASCII decimal digit> ;0-9 float = ["+" / "-"] *DIGIT ["." *DIGIT] For example: 1000000.0000001 1.333 -3.14 5.1.10.11 RFC 822 Address The "rfc822-address" data type is used to identify properties that contain a calendar address. The phrase component of the address may be used to match an unknown address with an otherwise known individual, group, or resource. The data type is as defined by the following notation: rfc822-address = addr-spec / [phrase] "<" addr-spec ">" addr-spec = local-part "@" domain ;RFC 822 address local-part = WORD *("." WORD) domain = domain-ref *("." domain-ref) domain-ref = ATOM Dawson/Stenerson 20 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 phrase = 1*WORD WORD = ATOM / quoted-string quoted-string = <"> *(qtext/quoted-pair) <"> ; Regular qtext or ; quoted chars. qtext = <any CHAR excepting <">, ; => may be folded "\" & CR, and including linear-white-space> quoted-pair ="\" CHAR ; may quote any char CHAR = <any a character from the selected character set> ATOM = 1*<any CHAR except specials, SPACE and CTLs> 5.1.10.12 UTC Offset The "utc -offset" data type is used to identify properties that contain an offset from UTC to local time. The data type is defined by the following notation: utc-offset = time-numzone ;As defined above in time data type For example, the following are UTC offsets for New York (five hours behind UTC) and Geneva (one hour ahead of UTC): -0500 ;New York +0100 ;Geneva 5.2 iCalendar Object The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar Object. However, multiple iCalendar Objects may be sequentially, grouped together. The first line and last line of the iCalendar Object must contain a pair of iCalendar Object delimiter strings. The syntax for a vCalendar Object is as follows: icalobject = "BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF [icalobject] The following is a simple example of an iCalendar Object: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T120000-0500 DTEND:19970714T235959-0500 DESCRIPTION:Bastile Day Party END:VEVENT END:VCALENDAR Dawson/Stenerson 21 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.3 Property A property is the definition of an individual attribute describing a calendar property or a calendar component. A property takes the following form: property = [group "."] propname [";" parmlist] ":" value CRLF propname = <any properties defined in this document> / iana-prop / x-token x-token = <The two characters "X-" or "x-" followed, with no intervening white space, by any atom> iana-prop = <A publicly defined extension property, registered with IANA, as specified by this document> The following is an example of a property: DTSTART:19960415T083000-05:00 This document places no imposed ordering of properties within an iCalendar Object. Property names, parameter names and parameter values (i.e., everything to the left of the ":" on a line) are case insensitive. For example, the property name "DUE" is the same as "due" and "Due". 5.4 Calendar Components The body of the iCalendar Object consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that with a particular calendar semantic. For example, the calendar component may specify a an event, a to-do, journal entry, time zone information, or free/busy time information, or alarm. The body of the iCalenar Object is defined by the following notation: icalbody = calprops 1*component calprops = [calscale] [geo] prodid [profile] [profile-version] [source] [name] version component = 1*(eventc / todoc / journalc / freebusyc / / timezonec) 5.4.1 Event Component An Event Calendar Component is a grouping of component properties and an optional alarm calendar component that represent a scheduled amount of time on a calendar. For example, it may be an activity; Dawson/Stenerson 22 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 such as a one-hour, department meeting from 8:00 AM to 9:00 AM, tomorrow. An Event Component is defined by the following notation: eventc = "BEGIN" ":" "VEVENT" CRLF *eventprop *alarmc "END" ":" "VEVENT" CRLF eventprop = *attach *attendee *categories [class] / [created] description dtend dtstart *exdate / *exrule *last-mod [location] [priority] / *related *resources *rdate *rrule / [resp-seq] / [seq] [status] [summary] [transp] / [uid] *url The Event Component can not be nested within another Calendar Component. Event components may be related to each other or to a To- do or Journal Calendar Component with the RELATED-TO property. The following is an example of the Event Calendar Component: BEGIN:VEVENT DTSTART:19970903T083000-0800 DTEND:19970903T110000-0500 DESCRIPTION:Annual Employee Review CLASS:PRIVATE CATEGORIES:BUSINESS,HUMAN RESOURCES END:VEVENT 5.4.2 To-do Component A To-do Calendar Component is a grouping of component properties and an optional alarm calendar component that represent an action-item or assignment. For example, it may be an item of work assigned to an individual; such as "turn in travel expense today". A To-do Component is defined by the following notation: todoc = "BEGIN" ":" "VTODO" CRLF *todoprop *alarmc "END" ":" "VTODO" CRLF todoprop = *attach *attendee *categories [class] [completed] / [created] description dtstart due *exdate / *exrule *last-mod [location] priority / *related *resources *rdate *rrule [resp-seq] / [seq] [status] [summary] [transp] [uid] *url The To-do Component can not be nested within another Calendar Component. If To-do components need to be related to each other or to an Event or Journal Calendar Component, they can specify a relationship with the RELATED-TO property. Dawson/Stenerson 23 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 The following is an example of a To-do Calendar Component: BEGIN:VTODO DTSTART:19970415T083000-0500 DUE:19970415T235959-0500 DESCRIPTION:1996 Income Tax Preparation CLASS:CONFIDENTIAL CATEGORIES:FAMILY,FINANCE PRIORITY:1 STATUS:NEEDS ACTION END:VEVENT 5.4.3 Journal Component A Journal Calendar Component is a grouping of component properties that represent one or more descriptive text on a particular calendar date. For example, it may be a journal entry of individual telephone contacts for the day or an ordered list of accomplishments for the day. A Journal Component is defined by the following notation: journalc = "BEGIN" ":" "VJOURNAL" CRLF *jourprop "END" ":" "VJOURNAL" CRLF jourprop = *attach *categories [class] [created] description / dtstart *last-mod *related [resp-seq] [seq] [uid] *url The Journal Component can not be nested within another Calendar Component. If Journal Components need to be related to each other or to an Event or To-Do Calendar Component, they can specify a relationship with the RELATED-TO property. The following is an example of the Journal Calendar Component: BEGIN:VJOURNAL DTSTART:19970317T083000 DESCRIPTION:1. Staff meeting: Participants include Joe, Lisa and Bob. Aurora project plans were reviewed. There is currently no budget reserves for this project. Lisa will escalate to management. Next meeting on Tuesday. 2. Telephone Conference: ABC Corp. sales representative called to discuss new printer. Promised to get us a demo by Friday. 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. Is looking into a loaner car. 654-2323 (tel). END:VJOURNAL 5.4.4 Free/Busy Component A Free/Busy Calendar Component is a grouping of component properties that represent free or busy time information. Typically, this component exists in an iCalendar Object that is being used to either request or return free or busy time information. Dawson/Stenerson 24 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 A Free/Busy Component is defined by the following notation: freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF *fbprop "END" ":" "VFREEBUSY" CRLF fbprop = *attendee [created] [duration] [dtend] [dtstart] / *freebusy *last-mod *related [resp-seq] [seq] [uid] / *url The Free/Busy Component can not be nested within another Calendar Component. Free/Busy components may be related to each other with the RELATED-TO property. Multiple Free/Busy Calendar Components may be specified within a iCalendar Object. This permits the grouping of Free/Busy information into logical collections, such as monthly groups of busy time information. The Free/Busy Calendar Component is intended for use in profiles involving requests for free time, requests for busy time, requests for both free and busy, and the associated replies. Free/Busy information can be expressed using the FREEBBUSY property. This property provides a terse representation of time periods. One or more FREEBUSY properties may be specified in the FREE/BUSY Calendar Component to describe the Free/Busy information. Optionally, the DTSTART and DTEND properties may be specified to express the start and end date and time for Free/Busy information in the Free/Busy Calendar Component. When present in a Free/Busy Calendar Component, they should be specified prior to any FREEBUSY properties. In a free time request, these properties may be used in combination with the DURATION property to express a request for a duration of free time within a given window of time. The recurrence properties (RRULE, EXRULE, RDATE, EXDATE) are not permitted within a Free/Busy Calendar Component. Any recurring events are resolved into their individual busy time periods using the FREEBUSY property. The following is an example of a Free/Busy Calendar Component: BEGIN:VFREEBUSY DTSTART:19971015T050000Z DTEND:19971016T050000Z FREEBUSY;VALUE=PERIOD-START:19971015T050000Z/PT8H30M, 19971015T160000Z/PT5H30M, 19971015T223000Z/PT6H30M END:VFREEBUSY 5.4.5 Alarm Component An Alarm Calendar Component is a grouping of component properties that is a reminder or alarm for an event or a to-do. The Alarm Calendar Component may only be specified in an event or to-do Dawson/Stenerson 25 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 calendar component. For example, it may define a reminder for a pending event or an overdue to-do. An Alarm Component is defined by the following notation: alarmc = "BEGIN" ":" "VALARM" CRLF *alarmprop "END" ":" "VALARM" CRLF alarmprop = *attach [created] [description] dtstart duration / *last-mod *related repeat [summary] *url The Alarm Component can only appear within either an Event or To-Do Calendar Component. Alarm Components can not be nested. The following is an example of the Alarm Calendar Component: BEGIN:VALARM DTSTART:19970317T133000Z REPEAT:4 DURATION:PT15M CATEGORIES:DISPLAY,AUDIO ATTACH:file:///mmedia/sounds/bell1.wav DESCRIPTION:Breakfast meeting with executive team at 8:30 AM END:VALARM 5.4.6 Timezone Component A time zone is unambiguously defined by the set of time measurement rules determined by the governing body for a given geographic area. These rules describe at a minimum the base offset from UTC for the time zone, often referred to as the Standard Time offset. Many locations adjust their Standard Time forward or backward by one hour, in order to accommodate seasonal changes in number of daylight hours, often referred to as Daylight Saving Time. Some locations adjust their time by a fraction of an hour. Standard Time is also known as Winter Time. Daylight Saving Time is also known as Advanced Time, Summer Time, or Legal Time in certain countries. The following table shows the changes in time zone rules for the eastern United States. Effective Transition Rule Date (Date/Time) Offset Abbreviation 1967-* last Sun in October, 02:00 -0500 EDT 1967-1973 last Sun in April, 02:00 -0400 EST 1974-1974 Jan 6, 02:00 -0400 EST 1975-1975 Feb 23, 02:00 -0400 EST 1976-1986 last Sun in April, 02:00 -0400 EST 1987-* first Sun in April, 02:00 -0400 EST Dawson/Stenerson 26 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Interoperability between two calendaring and scheduling applications, especially for recurring events and to-dos, is dependent on the ability to capture and convey date and time information in an unambiguous format. The specification of current time zone information is integral to this behavior. The Time Zone Calendar Component is a grouping of component properties that define a time zone description. The time zone description specifies the effective Standard Time or Daylight Savings Time rules for a particular time zone. The Timezone Component can not be nested within other Calendar Components. The Time Zone Component may be specified multiple times. If the Time Zone Component is missing, the recipient should assume all local times are relative to the recipient's time zone. The Time Zone Component should be specified in the iCalendar Object before any other Calendar Components. A Time Zone Component is defined by the following notation: timezonec = "BEGIN" ":" "VTIMEZONE" CRLF *tzprop "END" ":" "VTIMEZONE" CRLF tzprop = [created] [daylight] [dtend] dtstart [rdate / rrule] [tzname] tzoffset [tztrans] [uid] The Time Zone component is especially important for correct interpretation of recurring events and to-dos. If the iCalendar Object contains an event or to-do component that has a recurring date pattern (i.e., includes the RRULE property) or a list of date and local time values (i.e., includes the RDATE property), one or more Time Zone components must be specified, such that for the given range of the recurrence (i.e., the earliest instance to latest instance), there is valid time zone information for all instances. In other words, if all of the instances of the pattern is entirely within one offset observance, (e.g., all are in Standard Time), only one Time Zone Calendar Component need be present. If a time zone transition is crossed, then other Time Zone Components are needed. Further, if there are known changes to the rules for the time zone, even more Time Zone Components are needed. Each Time Zone Component consists of several properties. The CREATED property is a DATE-TIME value that indicates when the time zone description was created; the DAYLIGHT property is a BOOLEAN value indicating Standard Time (FALSE) or Daylight Savings Time (TRUE); the DSTART property is a DATE-TIME value indicating the effective start for the time zone information; the DTEND property is a DATE-TIME value indicating the effective end date for the time zone information; the TZOFFSET property is a UTC-OFFSET value indicating the UTC offset for the time zone (Standard Time or Daylight Savings Time); the TZTRANS property is a TIME value indicating the time of day after which the transition to the time zone occurs; the TZNAME property is the customary name for the time zone; the RRULE property is a TEXT property indicating the recurrence rule for the transition Dawson/Stenerson 27 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 to this time zone or alternatively, the RDATE property is a DATE-TIME property indicating the individual dates and times that the transition takes effect; and the UID is a TEXT value indicating a globally unique identifier for the time zone. The default for DAYLIGHT is FALSE or Standard Time. The following are examples of the Time Zone Calendar Component: BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19670101T000000 RRULE;BYDAY=-1SU;BYMONTH=10:YEARLY TZTRANS:020000 TZOFFSET:-0500 TZNAME:EST END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19870101T000000 RRULE;BYDAY=1SU;BYMONTH=4:YEARLY TZTRANS:020000 TZOFFSET:-0400 TZNAME:EDT END:VTIMEZONE 5.4.7 Calendar Properties The Calendar Properties are attributes that apply to the iCalendar Object, as a whole. These properties do not appear within a Calendar Component. They should be specified after the BEGIN:VCALENDAR properties and prior to any Calendar Component. 5.4.7.1 Calendar Scale This property is identified by the property name CALSCALE. This property defines the calendar scale used for the calendar information specified in the iCalendar Object. This specification is based on the Gregorian calendar scale. The Gregorian calendar scale is assumed if this property is not specified in the iCalendar Object. It is expected that other calendar scales will be defined in other specifications or by future versions of this specification. The property is defined by the following notation: calscale = "CALSCALE" ":" calvalue CRLF calvalue = "GREGORIAN" / iana-scale iana-scale = <Any other designator for a calendar scale registered with IANA> The following is an example of this property: Dawson/Stenerson 28 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 CALSCALE:GREGORIAN The data type for this property is TEXT. 5.4.7.2 Geographic Position This property is identified by the property name GEO. This property specifies information related to the global position of the entity represented by the iCalendar Object. The property value specifies longitude and latitude. The longitude represents the location east and west of the prime meridian as a positive or negative real number, respectively. The latitude represents the location north and south of the equator as a positive or negative real number, respectively. The property is defined by the following notation: geo = "GEO" ":" geovalue CRLF geovalue = (float ";" float )/ url The following is an example of this property: GEO:37.24,-17.87 The default data type for this property is FLOAT. Optionally, the data type for this property may be URL. The URL is the resource location for the geographical position value. 5.4.7.3 Product Identifier This property is identified by the property name PRODID. This property specifies the identifier for the product that created the iCalendar Object. The vendor of the implementation should assure that this is a globally unique identifier; using some technique such as an ISO 9070 FPI value. This calendar property must be specified in the iCalendar Object but can only appear once. The property is defined by the following notation: prodid = "prodid" ":" pidvalue CRLF pidvalue = (text / url) ;Any text that describes the product and version ;and that is generally assured of being unique.> The following is an example of this property: PRODID:-//ABC Corporation//NONSGML My Product//EN The default data type for this property is TEXT. Optionally, the data type may be URL. The URL is the resource location for the product identifier value. Dawson/Stenerson 29 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.4.7.4 Profile This property is identified by the property name PROFILE. This property defines the usage profile associated with the calendar object. When used in a MIME message entity, the value of this property must be the same as the Content-Type profile parameter value. This property can only appear once within the iCalendar Object. The property is defined by the following notation: profile = "PROFILE" ": profvalue CRLF profvalue = " component "-" action component = "EVENT" / "TODO" / "JOURNAL" / "FREEBUSY" / iana-component / x-token action = <Any IANA registered iCalendar action type.> iana-component = <Any other component registered with IANA> The following is an example of this property when the iCalendar Object is used to request a meeting: PROFILE:EVENT-REQUEST In the event that this property is not specified, the usage profile is undefined. The data type for this property is TEXT. 5.4.7.5 Profile Version This property is identified by the property name PROFILE-VERSION. This property specifies the identifier corresponding to the highest version number of the usage profile that was used in constructing the iCalendar Object. Values for this property are to be defined by registering an iCalendar usage profiles. The property is defined by the following notation: prof-version = "PROFILE-VERSION" ":" profvalue CRLF profvalue = iana-prfver / x-token iana-prfver = <A IANA registered iCalendar profile identifier> The following is an example of this property: PROFILE-VERSION:IPCS-1.0 The data type for this property is TEXT. Dawson/Stenerson 30 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.4.7.6 Source This property is identified by the property name SOURCE. This property is defined by the [MIME DIR] specification. The property identifies the URL for the source of the iCalendar Object. The source will usually be a resource on a calendaring and scheduling service. The property is defined by the following notation: source = "SOURCE" ":" url CRLF The following is an example of this property: SOURCE:http://xyz.corp.com/corp-cals/1997-events.or4 The data type for this property is URL. 5.4.7.7 Source Name This property is identified by the property name NAME. This property is defined by the [MIME DIR] specification. The property identifies the displayable, presentation name for the source of the iCalendar Object. The source name is a useful text to associate in the user- interface of an application with the value in the SOURCE property. The property is defined by the following notation: name = "NAME" ":" text CRLF The following is an example of this property: NAME:1997 Events Calendar for XYZ Corporation The data type for this property is TEXT. 5.4.7.8 Version This property is identified by the property name VERSION. This property specifies the identifier corresponding to the highest version number of the MIME Calendaring and Scheduling Content Type specification supported by the implementation that created the iCalendar Object. The value of this property must be "2.0" to correspond to this specification. This calendar property must appear within the iCalendar Object but can only appear once. The property is defined by the following notation: version = "VERSION" ":" vervalue CRLF vervalue = "2.0" / x-token The following is an example of this property: VERSION:2.0 Dawson/Stenerson 31 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 The data type for this property is TEXT. 5.5 Component Properties The following properties apply to either an event or to-do calendar object component. 5.5.1.1 Attachment This property is identified by the property name ATTACH. The property provides the capability to associate an external object with a calendar component. For example, a document to be reviewed at a scheduled event or the description of the process steps for a to-do. The property may only be specified within event, to-do, or journal calendar components. This property may be specified multiple times within an iCalendar Object. The property is defined by the following notation: attach = [group "."] "ATTACH" ":" url CRLF The following are examples of this property: ATTACH:<jsmith.part3.960817T083000.xyzMail@host1.com> ATTACH://xyzCorp.com/pub/reports/r-960812.ps The data type for this property is URL. 5.5.1.2 Attendee This property is identified by the property name ATTENDEE. The property defines an attendee within a calendar component. The property may only be specified within the event, to-do and free/busy calendar components. The property has the property parameters TYPE, for the type of attendee, ROLE, for the intended role of the attendee; STATUS, for the status of the attendee's participation; RSVP, for indicating whether the favor of a reply is requested; EXPECT, to indicate the expectation of the attendee's participation by the originator; and MEMBER, to indicate the group that the attendee belongs to. Multiple attendees may be specified by including multiple ATTENDEE properties within the MIME calendaring entity. The property data type default is RFC822-ADDRESS. The property data type may also be set to URL. This provides a useful mechanism to allow more than just the address of the attendee to be referenced. For example, the property value may refer to a URL. The property is defined by the following notation: Dawson/Stenerson 32 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 attendee = [group "."] "ATTENDEE" [";" attparamlist] ":" (rfc822-address / URL) CRLF ;Value must match default or explicit data type attparamlist = attparam / attparamlist ";" attparam / paramlist / paramlist ";" attparam / paramlist ";" attparamlist ";" attparam attparam = typeparm / roleparm / statusparm / rsvpparm / expectparm / memberparm typeparm = "TYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN") ; Otherwise not known ;Default value is UNKNOWN roleparm = "ROLE" "=" ("ATTENDEE" ; Indicates a regular attendee / "OWNER" ; Indicates owner of event or to-do / "ORGANIZER" ; Indicates organizer of event or to-do / "DELEGATE") ; Indicates delegate to event or to-do ;Default is ATTENDEE statusparm = "STATUS" "=" ("NEEDS-ACTION" ; Indicates event or to-do needs action / "ACCEPTED" ; Indicates event or to-do accepted / "DECLINED" ; Indicates event or to-do not accepted / "TENTATIVE" ; Indicates event or to-do tentatively ; accepted. Status may change in the future. / "COMPLETED" ; Indicates to-do was completed. ; COMPLETED property has date/time completed. / "DELEGATED" ; Indicateds event or to-do delegated ; to another ATTENDEE / "CANCELED") ; Indicates event or to-do canceled for ; ATTENDEE ;Default is NEEDS-ACTION rsvpparm = "RSVP" "=" ("YES" / "NO") ;Default is NO expectparm = "EXPECT" "=" ("FYI" ; Indicates request is for your info / "REQUIRE" ; Indicates presence is required / "REQUEST" ; Indicates presence is requested / "IMMEDIATE") ; Indicates an immediate response needed ;Default is FYI memberparm = rfc822-address ; Indicates a group or mailing list The following is an example of this property's use for a to-do: Dawson/Stenerson 33 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:jsmith@host1.com The following is an example of this property used for specifying multiple attendees to an event: ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:John Smith <jsmith@host1.com> ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:Henry Cabot <hcabot@host2.com> ATTENDEE;ROLE=DELEGATE;STATUS=CONFIRMED:Jane Doe <jdoe@host1.com> The following is an example of this property with the value specified as an URL reference to a vCard that contains the information about the attendee: ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;VALUE=URL: http://www.xyz.com/~myvcard.vcf The default data type for this property is RFC822-ADDRESS. The data type may be reset to URL; in which case the value is a location or message that contains the information that is to be used to specify the attendee address. 5.5.1.3 Categories This property is identified by the property name CATEGORIES. This property defines the categories for a calendar component. The property may be specified within the event, to-do or journal calendar component with an arbitrary text value. The property may also be specified within the alarm property with a value of the alarm category. More than one category may be specified as a list of categories separated by the COMMA character (ASCII decimal 44). The properties is defined by the following notation: categories = "CATEGORIES" [";" paramlist] ":" catvalue CRLF catvalue = cat1value [,cat1value] / cat2value [, cat2value] cat1value = "APPOINTMENT" / "BUSINESS" / "EDUCATION" / "HOLIDAY" / "MEETING" / "MISCELLANEOUS" / "NON-WORKING HOURS" / "NOT IN OFFICE" / "PERSONAL" / "PHONE CALL" / "SICK DAY" / "SPECIAL OCCASION" / "TRAVEL" / "VACATION" / word ;Used in event and to-do components only cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" / x-token / iana-word ;Used in alarm component only The following are examples of this property in an event, to-do or journal calendar component: CATEGORIES:APPOINTMENT,EDUCATION Dawson/Stenerson 34 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 CATEGORIES:MEETING The following are examples of this property in an alarm calendar component: CATEGORIES:AUDIO,DISPLAY CATEGORIES:PROCEDURE The data type for this property is TEXT. 5.5.1.4 Classification This property is identified by the property name CLASS. This property defines the access classification for a calendar component. The property may only be specified in an event, to-do or journal calendar component. The property may only be specified once. An access classification is only one component of the general security system within a calendar application. It provides a method of capturing the scope of the access the calendar owner intends for information within an individual calendar entry. The access classification of an individual iCalendar component is useful when measured along with the other security components of a calendar system (e.g., user authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications can not be completely defined by this specification alone. Additionally, due to the "blind" nature of most exchange processes using this specification, these access classifications can not serve as an enforcement statement for a system receiving an iCalendar Object . Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar component. The property is defined by the following notation: class = "CLASS" [";" paramlist] ":" classvalue CRLF classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / x-token ;Default is PUBLIC The following is an example of this property: CLASS:PUBLIC The data type for this property is TEXT. 5.5.1.5 Date/Time Created This property is identified by the property name CREATED. This property specifies the date and time that the calendar information was created. The property may be specified in any of the calendar components. The property may only be specified once. The date and time is an UTC value. Dawson/Stenerson 35 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 The property is defined by the following notation: created = "CREATED" ":" date-time CRLF The following is an example of this property: CREATED:19960329T133000Z The data type for this property is DATE-TIME. 5.5.1.6 Date/Time Completed This property is identified by the property name COMPLETED. This property defines the date and time that a to-do was actually completed. The property may be specified once in a to-do component. The date and time is a UTC value. The property is defined by the following notation: completed = "COMPLETED" ":" date-time CRLF The following is an example of this property: COMPLETED:19960401T235959Z This property is optional for MIME entities conforming to this content type. The data type for this property is DATE-TIME. 5.5.1.7 Daylight This property is identified by the property name DAYLIGHT. This property may only be specified in a Time Zone Calendar Component. This property specifies whether Daylight Saving Time (i.e., value is TRUE) or Standard Time (i.e., value is FALSE) is in effect for the time zone. The default value is FALSE or Standard Time. The property is defined by the following notation: daylight = "DAYLIGHT" ":" boolean CRLF ;Default value is FALSE The following is an example of this property: DAYLIGHT:TRUE ;Specifies DST in effect in time zone The data type for this property is BOOLEAN. 5.5.1.8 Description This property is identified by the property name DESCRIPTION. This property provides a more complete description of the calendar component, than that provided by the SUMMARY property. The property must be specified in the event, to-do and journal calendar Dawson/Stenerson 36 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 components. The property may be specified multiple times only within a journal calendar component. The property is defined by the following notation: description = "DESCRIPTION" [";" paramlist] text CRLF The following is an examples of the property with formatted line breaks in the property value: DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Meeting to provide technical= review for "Phoenix" design.=0D=0A= Happy Face Conference Room. Phoenix design team= must attend this meeting. RSVP to team leader. The following is an examples of the property with folding of long lines: DESCRIPTION:Last draft of the new novel is to be completed for the editor's proof today. The data type for this property is TEXT. 5.5.1.9 Due Date/Time This property is identified by the property name DUE. This property defines the date and time that a to-do is expected to be completed. The time can either be in local time, local time with UTC offset or UTC time. The property must be specified in a to-do calendar component, but may only be specified once. The property is defined by the following notation: due = "DUE" ":" date-time CRLF The following is an example of this property: DUE:19960401T235959Z The default data type for this property is DATE-TIME. The data type may be reset to DURATION. 5.5.1.10 Duration This property is identified by the property name DURATION. The property specifies a duration of time. The property may be specified in an event calendar component in order to specify a duration of the event, instead of an explicit end date/time. The property may be specified in a free/busy calendar component in order to specify the amount of free time being requested. The property may be specified in an alarm calendar component in order to specify the period between repeating alarms. The property is defined by the following notation: Dawson/Stenerson 37 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 duration = "DURATION" ":" duration CRLF The following is an example of this property that specifies an interval of time of 1 hour and zero minutes and zero seconds: DURATION:PT1H0M0S The following is an example of this property that specifies an interval of time of 15 minutes. DURATION:PT15M The data type for this property is DURATION. 5.5.1.11 Start Date/Time This property is identified by the property name DTSTART. This property may be specified within the event, free/busy, and time zone calendar components. Within the event calendar component, this property defines the start date and time for the event. The property is required in event calendar components. The time can either be in local time, local time with UTC offset or UTC time. The local time is only to be used to specify date and time values that do not need to be fixed. A recipient must assume their own time zone for data and time values that do not include time zone information. Events may have a start date/time but no end date/time. In that case, the event does not take up any time. Within the free/busy calendar component, this property defines the start date and time for the free or busy time information. The time must be specified in local time with UTC offset or UTC time. Within the time zone calendar component, this property defines the effective start date and time for a time zone specification. This property is required within time zone calendar components. The time must be specified as a UTC time. The property is defined by the following notation: dtstart = "DTSTART" ":" date-time CRLF The following is an example of this property: DTSTART:19960401T235959-0600 The data type for this property is DATE-TIME. 5.5.1.12 End Date/Time This property is identified by the property name DTEND. This property may be specified within the event, free/busy, and time zone calendar components. Dawson/Stenerson 38 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Within the event calendar component, this property defines the end date and time for the event. The property is required in event calendar components. The time can either be in local time, local time with UTC offset or UTC time. The local time is only to be used to specify date and time values that do not need to be fixed. A recipient must assume their own time zone for data and time values that do not include time zone information. Events may have an end date/time but no start date/time. In that case, the event does not take up any time. Within the free/busy calendar component, this property defines the end date and time for the free or busy time information. The time must be specified in local time with UTC offset or UTC time. Within the time zone calendar component, this property defines the effective end date and time for a time zone specification. This property is required within time zone calendar components. The time must be specified as a UTC time. The property is defined by the following notation: dtend = "DTEND" ":" date-time CRLF The following is an example of this property: DTEND:19960401T235959Z The data type for this property is DATE-TIME. 5.5.1.13 Exception Date/Times This property is identified by the property name EXDATE. This property defines the list of date/time exceptions for a recurring event or to-do component. The times can either be in local time, local time with UTC offset or UTC time. The property is defined by the following notation: exdate = "EXDATE" ":" date-time *["," date-time] CRLF The following is an example of this property: EXDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z The data type for this property is DATE-TIME. 5.5.1.14 Exception Rule This property is identified by the property name EXRULE. This property defines a rule or repeating pattern for an exception to a recurring event or to-do. This property may only be specified in the event and to-do calendar components. Dawson/Stenerson 39 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 This property is defined by the same property values and parameters as specified for the RRULE property. The property is defined by the following notation: exrule = "EXRULE" [";" rparamlist] ":" rvalue CRLF The following are examples of this property. Except every other week, on Tuesday and Thursday for 4 occurrences: EXRULE;COUNT=4;INTERVAL=2;BYDAY=TU,TH:WEEKLY Except daily for 10 occurrences: EXRULE;COUNT=10:DAILY Except yearly in June and July for 8 occurrences: EXRULE;COUNT=8;BYMONTH=6,7:YEARLY The data type for this property is TEXT. 5.5.1.15 Free/Busy Time This property is identified by the property name FREEBUSY. The property defines one or more free or busy time intervals. These time periods may be specified as either a start and end date-time or a start date-time and duration. The date and time is either local time with UTC offset or a UTC value. The FREEBUSY property may include the TYPE property parameter to specify the information defines a free or busy time interval. The property may also include the STATUS property parameter to specify the type of busy time. The STATUS parameter may be utilized by the application reading the busy time information in order to provide a richer view of the information. The property is defined by the following notation: freebusy = "FREEBUSY" [";" fbparmlist] ":" fbvalue CRLF fbparmlist = fbparam / paramlist ";" fbparam / fbparam ";" fbparmlist fbparam = fbtype / fbstatus fbtype = "TYPE" "=" ("FREE" or "BUSY") ;Default is BUSY fbstatus = "STATUS" "=" "BUSY" ;Represents busy time interval / "OUT" ;Represents out-of-office, non-working ;hours, or other unavailable interval Dawson/Stenerson 40 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 / "PRIVATE" ;Represents private unavailable time / "CONFIDENTIAL" ;Represents confidential unavailable ;time ;Default is BUSY fbvalue = period *["," period] ;Value must match default or explicit data type The following are some examples of this property: FREEBUSY;STATUS=OUT:19970308T160000Z/PT8H30M FREEBUSY;TYPE=FREE:19970308T160000Z/PT3H, 19970308T200000Z/PT1H FREEBUSY properties within the Free/Busy Calendar Component should be sorted in ascending order, based on start time and then end time, with the earliest periods first. The FREEBUSY property may specify more than one value, separated by the COMMA character (ASCII decimal 44). In such cases, the FREEBUSY property values should all be of the same STATUS (e.g., all values of a particular STATUS listed together in a single property). The data type for this property is PERIOD. 5.5.1.16 Last Modified This property is identified by the property name LAST-MODIFIED. The property specifies the date and time that the calendar information was last revised. The property value may include multiple "date-time" values in order to capture the sequence of modifications made to the calendar information. This property may be specified in the event, to-do, journal or free/busy calendar components. The data and time must be a UTC value. The property is defined by the following notation: last-mod = "LAST-MODIFIED" ":" date-time ["," date-time] CRLF The following is an example of this property: LAST-MODIFIED:19960817T133000Z The data type for this property is DATE-TIME. 5.5.1.17 Location This property is identified by the property name LOCATION. The property defines the intended location for the event or to-do calendar component. The property may only be specified within an event or to-do calendar component. The property is defined by the following notation: Dawson/Stenerson 41 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 location = "LOCATION [";" paramlist] ":" locavalue CRLF locavalue = text / url ;The value must be the same type as the ;default or explicit data type. The following are some examples of this property: LOCATION:Conference Room - F123, Bldg. 002 LOCATION;VALUE=URL:http://www.xyzcorp.com/~jsmith.vcf The default data type for this property is TEXT. The data type may be reset to URL. In the case of the data type being URL, the property value may reference a vCard object. This provides a useful mechanism to specify a location in terms of its electronic business card. 5.5.1.18 Priority This property is identified by the property name PRIORITY. The property defines the priority for event or to-do. The property may only be specified within an event or to-do calendar component. The value is an integer. A value of zero (ASCII decimal 48) specifies an undefined priority. A value of one (ASCII decimal 49) is the highest priority. A value of two (ASCII decimal 50) is the second highest priority. Subsequent numbers specify a decreasing ordinal priority. The property is specified by the following notation: priority = "PRIORITY" ":" integer CRLF ;Default is zero The following is an example of this property: PRIORITY:2 The data type for this property is INTEGER. 5.5.1.19 Related To This property is identified by the property name RELATED-TO. The property is used to represent relationships or references between one calendar component and another. The property may only be specified in the event, to-do and journal calendar components. The property value consists of the persistent, globally unique identifier of another MIME calendar component. This value would be represented in a MIME calendar component by the UID property. A linked relationship can be specified by a series of components that each, in turn, refer to their parent component. A group relationship can be specified by a number of components that all refer to one common parent component. Changes to a calendar component referenced by this property may impact the related calendar component. For example, if a group event Dawson/Stenerson 42 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 changes its start or end date or time, then the related, dependent events will need to have their start and end dates changed in a corresponding way. This property is intended only to provide information on the relationship of calendar components. It is up to the target calendar system to maintain any property implications of this relationship. The property is defined by the following notation: related = "RELATED-TO" [";" paramlist] ":" relvalue CRLF relvalue = text / url ;Value must be the same type as ;default or explicit data type The following is an example of this property: RELATED-TO:<jsmith.part7.19960817T083000.xyzMail@host3.com> RELATED-TO:19960401-080045-4000F192713-0052 The default data type for this property is TEXT. The data type may be reset to URL. 5.5.1.20 Recurrence Date/Times This property is identified by the property name RDATE. This property defines the list of date/times for a recurring event, to-do or time zone calendar component. This property may appear along with the RRULE property to define an aggregate set of repeating occurrences. When they both appear in an iCalendar Object, the recurring events are defined by the union of occurrences defined by both the RDATE and RRULE. The times can either be in local time, local time with UTC offset or UTC based time. If local time is used, the TIMEZONE component must be included in the iCalendar Object, otherwise the local time value will be interpreted relative to the time zone of the recipient. The period values for RDATE are specified using a specific start and a specific end basic format (period-explicit) or the period with a specific start and a specific duration basic format (period- start). The property is define by the following notation: rdate = "RDATE" ":" rdvalue *["," rdvalue] CRLF rdvalue = date-time / period ;Value must match the default or explicit data type The following is an example of this property: RDATE:19960403T020000Z/19960403T040000Z, 19960404T010000Z/PT3H The default data type for this property is DATE-TIME. The value may be reset to PERIOD. Dawson/Stenerson 43 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.5.1.21 Recurrence Rule This property is identified by the property name RRULE. This property defines a rule or repeating pattern for a recurring events, to-dos, or time zone definitions. The property may be specified in the event, to-do, or time zone calendar components. The property value identifies the type of recursion rule. Valid property values include HOURLY, to specify repeating events based on an interval of an hour or more; DAILY, to specify repeating events based on an interval of a day or more; WEEKLY, to specify repeating events based on an interval of a week or more; MONTHLY, to specify repeating events based on an interval of a month or more; and YEARLY, to specify repeating events based on an interval of a year or more. The property includes property parameters that further qualify the recurrence rule. The INTERVAL property parameter contains a positive integer representing how often the RRULE repeats. The default value is "1" or every hour for a HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule and every year for a YEARLY rule. For a HOURLY rule, the value may also be expressed as a duration value, specifying hours and minutes for the repeat interval. For example, PT1H30M, would represent a 1 hour and 30 minute repeat interval. The UNTIL property parameter defines a date-time value which bounds the RRULE. If not present, and the COUNT property parameter is also not present, the RRULE is considered to repeat forever. The COUNT property parameter defines the number of occurrences at which to bound the RRULE. This property parameter is ignored if the UNTIL property parameter is also present. The BYDAY property parameter specifies a COMMA character (ASCII decimal 44) separated list of days of the week; MO, indicates Monday; TU, indicates Tuesday; WE, indicates Wednesday; TH, indicates Thursday; FR, indicates Friday; SA, indicates Saturday; SU, indicates Sunday. Each of these parameter values may also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY RRULE. For example, within a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. The BYMONTHDAY property parameter specifies a COMMA character (ASCII decimal 44) separated list of days of the month. Valid values are 1 to 31 or -31 to -1. The BYYEARDAY property parameter specifies a COMMA character (ASCII decimal 44) separated list of days of the year. Valid values are 1 to Dawson/Stenerson 44 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 366 or -366 to -1. For example, -1 represents the last day of the year (December 31st). The BYSETPOS property parameter specifies a COMMA character (ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of events specified by the rule. Valid values are 1 to 366 or -366 to -1. It must only be used in conjunction with another Byxxx property parameter. For example "the last work day of the month" could be represented as: RRULE;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1:MONTHLY The BYWEEKNO property parameter specifies a comma separated list of weeks of the year. Valid values are 1 to 52. This corresponds to weeks according to week numbering as defined in [ISO 8601]. That is, a week as "A seven day period within a calendar year, starting on a Monday and identified by its ordinal number within the year; the first calendar week of the year is the one that includes the first Thursday of that year." This property parameter is only valid for YEARLY rules. The BYMONTH property parameter specifies a comma separated list of months of the year. Valid values are 1 to 12. The WKST property parameter specifies the day on which the workweek starts. Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant when a WEEKLY RRULE has an interval greater than 1. The default value is MO. If two different Byxxx property parameters are specified within the RRULE, the recurrence occurrence must meet both criteria. If Byxxx property parameter values are found which are beyond the available scope (ie, BYMONTHDAY=-30 in February), they are simply ignored. If a positive range limit is beyond the available scope, it will be interpreted as -1. Likewise, if a negative range limits beyond the available scope, it will be interpreted as +1. The RRULE property requires referencing the DTSTART, DTEND or DURATION properties in the iCalendar object to calculate the Event or To-do instances. The DTSTART and DTEND pair or DTSTART and DURATION pair, specified within the iCalendar object defines the first instance of the recursion. When used with a recurrence rule, the DTSTART and DTEND properties must be specified in local time and the appropriate set of TIMEZONE components must be included. For detail on the usage of the TIMEZONE component, see the Time Zone Calendar Component definition. Any duration associated with the iCalendar Object applies to all members of the generated recursion. Any modified duration for specific recurrences would have to be explicitly specified using the RDATE property. Dawson/Stenerson 45 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 This property is defined by the following notation: rrule = "RRULE" [rparamlist] ":" rvalue CRLF rparamlist = rparam / rparamlist ";" rparam / paramlist / paramlist ";" rparam / paramlist ";" rparamlist ";" rparam rparam = "UNTIL" "=" enddate / "COUNT" "=" interval / "INTERVAL" "=" rinterval / "BYDAY" "=" bdweekdaylist / "BYMONTHDAY" "=" bmdaylist / "BYYEARDAY" "=" bydaylist / "BYSETPOS" "=" bsplist / "BYWEEKNO" "=" bwdaylist / "BYMONTH" "=" bmlist / "WKST" "=" weekday / "X-" word "=" word rvalue = "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY" rinterval = interval ; For any rvalue / duration ; Only for rvalue = HOURLY DIGIT =<any ASCII decimal digit> ;0-9 digits = 1*DIGIT interval = digits enddate = date ;A UTC value plus = "+" minus = "-" ordmoday = 1*2digits ;1 to 31 ordwk = 1*2digits ;1 to 52 ordyrday = 1*3digits ;1 to 366 daynumber = (plus / minus) ordmoday weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" > bdweekdaynum = [daynumber] weekday bdweekdaylist = bdweekdaynum / bdweekdaynum "," *(bdweekdaynum) bmposday = [plus] ordmoday bmnegday = minus ordmoday Dawson/Stenerson 46 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 bmdaylist = bmposday *("," bmposday / bmnegday) / bmnegday *("," bmnegday / bmposday) byposday = [plus] ordyrday bynegday = minus ordyrday bydaylist = byposday *("," byposday / bynegday) / bynegday *("," bynegday / byposday) bsplist = byposday *("," byposday / bynegday) / bynegday *("," bynegday / byposday) bwposday = [plus] ordwk bwnegday = minus ordwk bwdaylist = bwposday *("," bwposday / bwnegday) / bwnegday *("," bwnegday / bwposday) bmposmon = 1*2digits ;1 to 12 bmlist = bmposmon *("," bmposmon) Examples of this property include the following. Daily for 10 occurrences: RRULE;COUNT=10:DAILY Daily until 12/24/94: RRULE;UNTIL=19941224T000000Z:DAILY Every other day - forever: RRULE;INTERVAL=2:DAILY Every 10 days, 5 occurrences: RRULE;COUNT=5;INTERVAL=10:DAILY Weekly for 10 occurrences RRULE;COUNT=10:WEEKLY Weekly until 12/24/94 RRULE;UNTIL=19941224T000000Z:WEEKLY Every other week - forever: RRULE;INTERVAL=2;WKST=SU:WEEKLY Weekly on Tuesday and Thursday for 5 weeks: Dawson/Stenerson 47 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 RRULE;INTERVAL=5;WKST=SU;BYDAY=TU,TH:WEEKLY Every other week on Monday, Wednesday and Friday until 12/24/94: RRULE;INTERVAL=2;WKST=SU;BYDAY=MO,WE,FR;=UNTIL=19941224T000000Z: WEEKLY Every other week on Tuesday and Thursday, for 8 occurrences: RRULE;INTERVAL=2;WKST=SU;COUNT=8;BYDAY=TU,TH:WEEKLY Monthly on the 1st Friday for ten occurrences: RRULE;COUNT=10;BYDAY=1FR:MONTHLY Monthly on the 1st Friday until 12/24/94: RRULE;UNTIL=19941224T000000Z;BYDAY=1FR:MONTHLY Every other month on the 1st and last Sunday of the month for 10occurrences: RRULE;COUNT=10;BYDAY=1SU,-1SU:MONTHLY Monthly on the second to last Monday of the month for 6 months: RRULE;COUNT=6;BYDAY=-2MO:MONTHLY Monthly on the third to the last day of the month, forever: RRULE;BYMONTHDAY=-3:MONTHLY Monthly on the 2nd and 15th of the month for 10 occurrences: RRULE;COUNT=10;BYMONTHDAY=2,15:MONTHLY Monthly on the first and last day of the month for 10 occurrences: RRULE;COUNT=10;BYMONTHDAY=1,-1:MONTHLY Every 18 months on the 10th thru 15th of the month for 10 occurrences: RRULE;COUNT=10;INTERVAL=18;BYMONTHDAY=10,11,12,13,14,15:MONTHLY Monthly on the second to the last day for 5 months. So, if the start date is August 1996, the event would repeat on 8/30/96, 9/29/96, 10/30/96, 11/29/96, and 12/30/96: RRULE;COUNT=5;BYMONTHDAY=-2:MONTHLY Yearly in June and July for 10 occurrences: RRULE;COUNT=10;BYMONTH=6,7:YEARLY Dawson/Stenerson 48 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Every other year on January, February, and March for 10 occurrences: RRULE;COUNT=10;INTERVAL=2;BYMONTH=1,2,3:YEARLY Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: RRULE;COUNT=10;INTERVAL=3;BYYEARDAY=1,100,200:YEARLY Every 20th Monday of the year, forever: RRULE;BYDAY=20MO:YEARLY Monday of Week No. 20, forever: RRULE;BYWEEKNO=20;BYDAY=MO:YEARLY Every Thursday in March, forever: RRULE;BYDAY=TH;BYMONTH=3:YEARLY Every Thursday, but only in the summer, forever: RRULE;BYDAY=TH;BYMONTH=6,7,8:YEARLY Every Friday the 13th, forever: RRULE;BYDAY=FR;BYMONTHDAY=13:MONTHLY The first Saturday that follows the first Sunday of the month, forever: RRULE;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13:MONTHLY Every four years, the first Tuesday after a Monday in November, forever (U.S. Election day): RRULE;INTERVAL=4;BYDAY=TU;BYMONTHDAY=7,8,9,10,11,12,13:YEARLY The 3rd instance into the month of any of Tuesday, Wednesday or Thursday, for the next 3 months: RRULE;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3:MONTHLY The 2nd to last weekday of the month" RRULE;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2:MONTHLY The data type for this property is TEXT. 5.5.1.22 Resources This property is identified by the property name RESOURCES. This property defines the equipment or resources needed for the event or to-do. The property value is an arbitrary text. The property may only Dawson/Stenerson 49 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 be specified in the event or to-do calendar component. More than one resource may be specified as a list of resources separated by the COMMA character (ASCII decimal 44). The property is defined by the following notation: resource = "RESOURCES" [";" paramlist] ":" resvalist CRLF resvalist = resvalue / resvalue "," resvalist resvalue = "CATERING" / "CHAIRS" / "COMPUTER PROJECTOR" / "EASEL" / "OVERHEAD PROJECTOR" / "SPEAKER PHONE" / "TABLE" / "TV" / "VCR" / "VIDEO PHONE" / "VEHICLE" / word The following is an example of this property: RESOURCES:EASEL,PROJECTOR,VCR The data type for this property is TEXT. 5.5.1.23 Response Sequence Number This property is identified by the property name RESPONSE-SEQUENCE. This property defines the revision sequence of the calendar component. The property may only be specified in an event, to-do, journal or free/busy calendar component. This property is needed to properly handle the receipt and processing of a sequence of MIME calendar components that have been delivered out of order. Such is the case for store-and-forward based transports. The first response to an a request is created with response sequence number of "0" (ASCII decimal 48). If the value is non-zero, it must be specified. It is incremented each time another reply is sent. The property is defined by the following notation: respseq = "RESPONSE-SEQUENCE" ":" integer CRLF ;Default is "0". The following is an example of this property: RESPONSE-SEQUENCE:1 The data type for this property is INTEGER. 5.5.1.24 Sequence Number This property is identified by the property name SEQUENCE. This property defines the revision sequence of the calendar component used in a request. The property may only be specified in an event, to-do, journal or free/busy calendar component. This property is needed to properly handle the receipt and processing of a sequence of MIME calendar components that have been delivered out of order. Such is the case for store-and-forward based transports. The first request is Dawson/Stenerson 50 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 created with a sequence number of "0" (ASCII decimal 48). It is incremented each time the ORGANIZER or OWNER issues a revision to the request. The property is defined by the following notation: sequence = "SEQUENCE" ":" integer CRLF ;Default is "0". The following is an example of this property: SEQUENCE:1 The data type for this property is INTEGER. 5.5.1.25 Status This property is identified by the property name STATUS. This property defines the overall status for the calendar component. This property may only be specified in the event and to-do calendar components. When specified in an event calendar component, the property is used to specify the general consensus for the meeting. The property may only be specified in the to-do calendar component when the ATTENDEE property is not specified. For group scheduled events and to-dos, the status is specified on an individual basis in the ATTENDEE property. The property is defined by the following notation: status = "STATUS" [";" paramlist] ":" statvalue CRLF statvalue = "NEEDS ACTION" ;Indicates to-do needs action. / "COMPLETED" ;Indicates to-do completed / "TENTATIVE" ;Indicates event is being ;tentatively scheduled / "CONFIRMED" ;Indicates event is definite / "CANCELLED" ;Indicates event was canceled The following is an example of this property: STATUS:TENTATIVE The data type for this property is TEXT. 5.5.1.26 Summary This property is identified by the property name SUMMARY. This property defines a short summary or subject for the calendar component. The property may only be specified in the event, to-do and alarm calendar component. The property is defined by the following notation: summary = "SUMMARY" [";" paramlist] ":" text CRLF Dawson/Stenerson 51 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 The following is an example of this property: SUMMARY:Department Party The data type for this property is TEXT. 5.5.1.27 Time Transparency This property is identified by the property name TRANSP. This property defines whether an event is transparent or not to free/busy time searches. This property may only be specified in an event calendar component. The property is specified by the following notation: transp = "TRANSP" [";" paramlist] ":" transvalue CRLF transvalue = "BUSY" ;Opaque/blocks on free/busy searches ;Default value is BUSY / "OUT" ;Opaque/blocks on free/busy searches / "PRIVATE" ;Opaque/blocks on free/busy searches / "CONFIDENTIAL" ;Opaque/blocks on free/busy searches / "TRANSPARENT" ;Transparent on free/time searches The following is an example of this property for an event that is transparent or does not block on free/busy time searches: TRANSP:TRANSPARENT The following is an example of this property for an event that is opaque or blocks on free/busy time searches: TRANSP:BUSY The data type for this property is TEXT. 5.5.1.28 Time Zone Name This property is identified by the property name TZNAME. This property specifies the customary designation for a time zone descripiton. This property may only be specified in the Time Zone Calendar Component. This property is defined by the following notation: tzname = "TZNAME" [";" paramlist] ":" text CRLF The following are examples of this property: TZNAME: EST TZNAME: PDT The data type for this property is TEXT. Dawson/Stenerson 52 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.5.1.29 Time Zone Offset This property is identified by the property name TZOFFSET. This property specifies the offset from UTC for a time zone. This property may only be specified in a Time Zone Calendar Component. A Time Zone Calendar Component must include this property. The property value is a signed numeric indicating the number of hours and possibly minutes from UTC. Positive numbers represents time zones east, or ahead of UTC. Negative numbers represents time zones west of, or behind UTC. The property is defined by the following notation: tzoffset = "TZOFFSET" ":" utc-offset CRLF The following are examples of this property: TZOFFSET:-0500 TZOFFSET:+0530 The data type for this property is UTC-OFFSET. 5.5.1.30 Time Zone Transition Time This property is identified by the property name TZTRANS. This property specifies the time of day when a time zone transitions to the specified time observance (e.g., into daylight savings time). The property is defined by the following notation: tztrans = "TZTRANS" ":" time CRLF The following are examples of this property: TZTRANS:020000 The data type for this property is TIME. 5.5.1.31 Uniform Resource Locator This property is identified by the property name URL. This property defines a Uniform Resource Locator (URL) associated with the iCalendar Object. This property may be specified in the event, to-do, journal, free/busy, and alarm calendar components. The property is defined by the following notation: url = "URL" ":" url CRLF The following is an example of this property: URL:http://abc.com/pub/calendars/jsmith/mytime.or3 The data type for this property is URL. Dawson/Stenerson 53 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 5.5.1.32 Unique Identifier This property is identified by the property name UID. This property defines the persistent, globally unique identifier for the calendar component. The property may be specified in the event and to-do calendar components. The property is defined by the following notation: uid = "UID" [";" paramlist] ":" text CRLF The following is an example of this property: UID:19960401-080045-4000F192713-0052 This property is an important method for group scheduling applications to match requests with later replies, modifications or deletion requests. Calendaring and scheduling applications that do not generate this property in event and to-do calendar components may be limiting their interoperability with other group scheduling applications. The data type for this property is TEXT. 5.5.1.33 Non-standard Properties The MIME Calendaring and Scheduling Content Type provides a "standard mechanism for doing non-standard things". This extension support is provided for implementers to "push the envelope" on the existing version of the specification. Extension properties are specified by property and/or property parameter names that have the prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER X character followed by the HYPEN-MINUS character). It is recommended that vendors concatenate onto this sentinel another short prefix text to identify the vendor. This will facilitate readability of the extensions and minimize possible collision of names between different vendors. User agents that support this content type are expected to be able to parse the extension properties and property parameters but may ignore them. The property is defined by the following notation: extension = "X-" [vendorid] word [";" paramlist] ":" value vendorid = 1*char "-" ;Vendor identification prefix text The following might be the ABC vendor's extension for an audio-clip form of subject property: X-ABC-MMSUBJ;TYPE=WAVE; VALUE=URL: http://load.noise.org/mysubj.wav At present, there is no registration authority for names of extension properties and property parameters. The data type for this property Dawson/Stenerson 54 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 is TEXT. Optionally, the data type may be any of the other valid data types. 5.6 Complete Format Definition The following modified Backus-Naur Notation (BNF) is provided to assist developers in building parsers for the properties of this content type. CHAR = <Any character in the selected character set> DIGIT = <Any ASCII decimal digit> ;0-9 CTL = <Any control character in the selected character set> CR = <ASCII CR, carriage return, ASCII decimal 13> LF = <ASCII LF, line feed, ASCII decimal 10> SPACE = <ASCII SP, space, ASCII decimal 32> HTAB = <ASCII HT, horizontal tab, ASCII decimal 9> CLRF = CR LF LWSP-char = SPACE / HTAB ;Semantics equals SPACE linear-white-space = 1*(CRLF LWSP-char) ;Semantics is SPACE CRLF, which indicates folding WORD = ATOM / quoted-string quoted-string = <"> *(qtext/quoted-pair) <"> ; Regular qtext or ; quoted chars. qtext = <any CHAR excepting <">, ; => may be folded "\" & CR, and including linear-white-space> quoted-pair ="\" CHAR ; may quote any char ATOM = 1*<any CHAR except specials, SPACE and CTLs> ; ;Definition of a line of content information ; contentline = [group "."] name [";" paramlist] ":" value CRLF ;Folding permitted on content lines. group = atom ;As defined in [RFC 822] name = x-name / iana-name ;An iCalendar attribute/property x-name = <The two characters "X-" or "x-" followed, with no intervening white space, by any atom> iana-name = <A publicly defined name, registered with IANA> paramlist = parameter / paramlist ";" parameter parameter = encodingparm / valuetypeparm ;If not present => inline value / charsetparm / languageparm / [parmtype "="] parmvalues encodingparm = "encoding" "=" encodetype Dawson/Stenerson 55 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 encodetype = "8bit" ;From [RFC 2045] / "7bit" ;From [RFC 2045] / "base64" ;From [RFC 2045] / "quoted-printable" ;From [RFC 2045] valuetypeparm = "value" "=" valuetype valuetype = "url" / "text" / "date" / "time" / "date-time" / "period" / "duration" / "boolean" / "integer" / "float" / "rfc822-address" / "utc-offset" / x-token / iana-value iana-value = <A publicly defined extension value type, registered with IANA, as specified by this document> charsetparm = "charset" "=" charset ;As defined in [RFC 2047] languageparm = "language" "=" language ;As defined in [RFC 1766] parmtype = x-token / iana-ptype iana-ptype = <A publicly defined extension parameter type, registered with IANA, as specified by this document> parmvalues = parmvalue / parmvalues "," parmvalue parmvalue = x-name / iana-pvalue iana-pvalue = <A publicly defined extension parameter value, registered with IANA, as specified by this document> value = url / text / date / time/ date-time / period / / duration / boolean / integer / float / rfc822-address / utc-offset / iana-value iana-value = <A publicly defined property value data type, registered with IANA, as defined in this document> ; ;Data Types ; url = <As defined by [RFC 1738]> Dawson/Stenerson 56 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 text = <Any CHAR include a bare CR or a bare LF but not a CRLF sequence> date-fullyear = 4DIGIT date-month = 2DIGIT ;01-12 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 ;based on month/year full-date = date-fullyear date-month date-mday date = fulldate *["," fulldate] time-hour = 2DIGIT ;00-24 time-minute = 2DIGIT ;00-60 time-second = 2DIGIT ;00-59 time-numzone = ("+" / "-") time-hour time-minute time-zone = "Z" / time-numzone full-time = time-hour time-minute time-second [time-zone] time = fulltime *["," fulltime] date-time = date "T" time ;As specified above in date and time dur-second = 1*DIGIT "S" dur-minute = 1*DIGIT "M" [dur-second] dur-hour = 1*DIGIT "H" [dur-minute] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1*DIGIT "W" dur-day = 1*DIGIT "D" dur-month = 1*DIGIT "M" [dur-day] dur-year = 1*DIGIT "Y" [dur-month] dur-date = (dur-day / dur-month / dur-year) [dur-time] duration = "P" (dur-date / dur-time / dur-week) period-explicit = date-time "/" date-time ;ISO 8601 complete representation basic format for a period of time ;consisting of a start and end. The start must be before the end. period-start = date-time "/" duration ;ISO 8601 complete representation basic format for a period of time ;consisting of a start and duration of time. period = period-explicit / period-start boolean = "TRUE" / "FALSE" integer = ["+" / "-"] *DIGIT float = ["+" / "-"] *DIGIT ["." *DIGIT] rfc822-address = addr-spec / [phrase] "<" addr-spec ">" addr-spec = local-part "@" domain ;RFC 822 address local-part = WORD *("." WORD) domain = domain-ref *("." domain-ref) Dawson/Stenerson 57 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 domain-ref = ATOM phrase = 1*WORD utc-offset = time-numzone ;As defined above in time ; ;Definition of an iCalendar Object ; icalobject = "BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF [icalobject] ; ;Definition of an iCalendar Property ; property = [group "."] propname [";" parmlist] ":" value CRLF propname = <any properties defined in this document> / iana-prop / x-token x-token = <The two characters "X-" or "x-" followed, with no intervening white space, by any atom> iana-prop = <A publicly defined extension property, registered with IANA, as specified by this document> ; ;Definition of the Calendar Components and Calendar Properties ; icalbody = calprops 1*component calprops = [calscale] [geo] prodid [profile] [prof-version] [source] [name] version component = 1*(eventc / todoc / journalc / freebusyc / / timezonec) ;Event Component eventc = "BEGIN" ":" "VEVENT" CRLF *eventprop *alarmc "END" ":" "VEVENT" CRLF eventprop = *attach *attendee *categories [class] / [created] description dtend dtstart *exdate / *exrule *last-mod [location] [priority] / *related *resources *rdate *rrule / [resp-seq] / [seq] [status] [summary] [transp] / [uid] *url ;To-do Component todoc = "BEGIN" ":" "VTODO" CRLF *todoprop *alarmc "END" ":" "VTODO" CRLF Dawson/Stenerson 58 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 todoprop = *attach *attendee *categories [class] [completed] / [created] description dtstart due *exdate / *exrule *last-mod [location] priority / *related *resources *rdate *rrule [resp-seq] / [seq] [status] [summary] [transp] [uid] *url ;Journal Component journalc = "BEGIN" ":" "VJOURNAL" CRLF *jourprop "END" ":" "VJOURNAL" CRLF jourprop = *attach *categories [class] [created] description / dtstart *last-mod *related [resp-seq] [seq] [uid] *url ;Free/Busy Component freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF *fbprop "END" ":" "VFREEBUSY" CRLF fbprop = *attendee [created] [duration] [dtend] [dtstart] / *freebusy *last-mod *related [resp-seq] [seq] [uid] / *url ;Alarm Component alarmc = "BEGIN" ":" "VALARM" CRLF *alarmprop "END" ":" "VALARM" CRLF alarmprop = *attach [created] [description] dtstart duration / *last-mod *related repeat [summary] *url ;Time Zone Component timezonec = "BEGIN" ":" "VTIMEZONE" CRLF *tzprop "END" ":" "VTIMEZONE" CRLF tzprop = [created] [daylight] [dtend] dtstart [rdate / rrule] [tzname] tzoffset [tztrans] [uid] ; ;Definition of the Calendar Properties ; calscale = "CALSCALE" ":" calvalue CRLF calvalue = "GREGORIAN" / iana-scale iana-scale = <Any other designator for a calendar scale registered with IANA> geo = "GEO" ":" geovalue CRLF geovalue = (float ";" float )/ url prodid = "prodid" ":" pidvalue CRLF pidvalue = (guid-text / url) ;Any text that describes the product and version ;and that is generally assured of being unique.> Dawson/Stenerson 59 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 profile = "PROFILE" ": profvalue CRLF profvalue = " component "-" action component = "EVENT" / "TODO" / "JOURNAL" / "FREEBUSY" / iana-component / x-token action = <Any IANA registered iCalendar action type.> iana-component = <Any other component registered with IANA> prof-version = "PROFILE-VERSION" ":" profvalue CRLF profvalue = iana-prfver / x-token iana-prfver = <A IANA registered iCalendar profile identifier> source = "SOURCE" ":" url CRLF name = "NAME" ":" text CRLF version = "VERSION" ":" vervalue CRLF vervalue = "2.0" / x-token ;Component Properties attach = [group "."] "ATTACH" ":" url CRLF attendee = [group "."] "ATTENDEE" [";" attparamlist] ":" (rfc822-address / url) CRLF attparamlist = attparam / attparamlist ";" attparam / paramlist / paramlist ";" attparam / paramlist ";" attparamlist ";" attparam attparam = typeparm / roleparm / statusparm / rsvpparm / expectparm / memberparm typeparm = "TYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN") ; Otherwise not known ;Default value is UNKNOWN roleparm = "ROLE" "=" ("ATTENDEE" ; Indicates a regular attendee / "OWNER" ; Indicates owner of event or to-do / "ORGANIZER" ; Indicates organizer of event or to-do / "DELEGATE") ; Indicates delegate to event or to-do ;Default is ATTENDEE statusparm = "STATUS" "=" ("NEEDS-ACTION" ; Indicates event or to-do needs action / "ACCEPTED" ; Indicates event or to-do accepted / "DECLINED" ; Indicates event or to-do not accepted / "TENTATIVE" ; Indicates event or to-do tentatively ; accepted. Status may change in the future. / "COMPLETED" ; Indicates to-do was completed. ; COMPLETED property has date/time completed. Dawson/Stenerson 60 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 / "DELEGATED" ; Indicateds event or to-do delegated ; to another ATTENDEE / "CANCELED") ; Indicates event or to-do canceled for ; ATTENDEE ;Default is NEEDS-ACTION rsvpparm = "RSVP" "=" ("YES" / "NO") ;Default is NO expectparm = "EXPECT" "=" ("FYI" ; Indicates request is for your info / "REQUIRE" ; Indicates presence is required / "REQUEST" ; Indicates presence is requested / "IMMEDIATE") ; Indicates an immediate response needed ;Default is FYI memberparm = rfc822-address ; Indicates a group or mailing list categories = "CATEGORIES" [";" paramlist] ":" catvalue CRLF catvalue = cat1value [,cat1value] / cat2value [, cat2value] cat1value = "APPOINTMENT" / "BUSINESS" / "EDUCATION" / "HOLIDAY" / "MEETING" / "MISCELLANEOUS" / "NON-WORKING HOURS" / "NOT IN OFFICE" / "PERSONAL" / "PHONE CALL" / "SICK DAY" / "SPECIAL OCCASION" / "TRAVEL" / "VACATION" / word ;Used in event and to-do components cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" / x-token / iana-word ;Used in alarm component class = "CLASS" [";" paramlist] ":" classvalue CRLF classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / x-token ;Default is PUBLIC created = "CREATED" ":" date-time CRLF completed = "COMPLETED" ":" date-time CRLF daylight = "DAYLIGHT" ":" boolean CRLF ;Default value is FALSE description = "DESCRIPTION" [";" paramlist] text CRLF due = "DUE" ":" date-time CRLF duration = "DURATION" ":" duration CRLF dtstart = "DTSTART" ":" date-time CRLF dtend = "DTEND" ":" date-time CRLF exdate = "EXDATE" ":" date-time *["," date-time] CRLF Dawson/Stenerson 61 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 exrule = "EXRULE" [";" rparamlist] ":" rvalue CRLF freebusy = "FREEBUSY" [";" fbparmlist] ":" fbvalue CRLF fbparmlist = fbparam / paramlist ";" fbparam / fbparam ";" fbparmlist fbparam = fbtype / fbstatus fbtype = "TYPE" "=" ("FREE" or "BUSY") ;Default is BUSY fbstatus = "STATUS" "=" "BUSY" ;Represents busy time interval / "OUT" ;Represents out-of-office, non-working ;hours, or other unavailable interval / "PRIVATE" ;Represents private unavailable time / "CONFIDENTIAL" ;Represents confidential unavailable ;time ;Default is BUSY fbvalue = period ["," period] ;Value must match default or explicit data type last-mod = "LAST-MODIFIED" ":" date-time ["," date-time] CRLF location = "LOCATION [";" paramlist] ":" locavalue CRLF locavalue = text / url ;The value must be the same type as the ;default or explicit data type. priority = "PRIORITY" ":" integer CRLF ;Default is zero related-to = "RELATED-TO" [";" paramlist] ":" relvalue CRLF relvalue = text / url ;Value must be the same type as ;default or explicit data type rdate = "RDATE" ":" rdvalue *["," rdvalue] CRLF rdvalue = date-time / period ;Value must match default or explicit data type ; ;Definition of recurrence rule ;rrule = "RRULE" [rparamlist] ":" rvalue CRLF rparamlist = rparam / rparamlist ";" rparam / paramlist / paramlist ";" rparam / paramlist ";" rparamlist ";" rparam rparam = "UNTIL" "=" enddate / "COUNT" "=" interval / "INTERVAL" "=" rinterval / "BYDAY" "=" bdweekdaylist / "BYMONTHDAY" "=" bmdaylist / "BYYEARDAY" "=" bydaylist Dawson/Stenerson 62 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 / "BYSETPOS" "=" bsplist / "BYWEEKNO" "=" bwdaylist / "BYMONTH" "=" bmlist / "WKST" "=" weekday / "X-" word "=" word rvalue = "HOURLY" / "DAILY" / "WEEKLY" / "YEARLY" rinterval = interval ; For any rvalue / duration ; Only for rvalue = HOURLY digits = 1*digit interval = digits enddate = date ;A UTC value plus = "+" minus = "-" ordmoday = 1*2digits ;1 to 31 ordwk = 1*2digits ;1 to 52 ordyrday = 1*3digits ;1 to 366 daynumber = (plus / minus) ordmoday weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" > bdweekdaynum = [daynumber] weekday bdweekdaylist = bdweekdaynum / bdweekdaynum "," *(bdweekdaynum) bmposday = [plus] ordmoday bmnegday = minus ordmoday bmdaylist = bmposday *("," bmposday / bmnegday) / bmnegday *("," bmnegday / bmposday) byposday = [plus] ordyrday bynegday = minus ordyrday bydaylist = byposday *("," byposday / bynegday) / bynegday *("," bynegday / byposday) bsplist = byposday *("," byposday / bynegday) / bynegday *("," bynegday / byposday) bwposday = [plus] ordwk Dawson/Stenerson 63 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 bwnegday = minus ordwk bwdaylist = bwposday *("," bwposday / bwnegday) / bwnegday *("," bwnegday / bwposday) bmposmon = 1*2digits ;1 to 12 bmlist = bmposmon *("," bmposmon) resource = "RESOURCES" [";" paramlist] ":" resvalist CRLF resvalist = resvalue / resvalue "," resvalist resvalue = "CATERING" / "CHAIRS" / "COMPUTER PROJECTOR" / "EASEL" / "OVERHEAD PROJECTOR" / "SPEAKER PHONE" / "TABLE" / "TV" / "VCR" / "VIDEO PHONE" / "VEHICLE" / word respseq = "RESPONSE-SEQUENCE" ":" integer CRLF ;Default is "0". sequence = "SEQUENCE" ":" integer CRLF ;Default is "0". status = "STATUS" [";" paramlist] ":" statvalue CRLF statvalue = "NEEDS ACTION" ;Indicates to-do needs action. / "COMPLETED" ;Indicates to-do completed / "TENTATIVE" ;Indicates event is being ;tentatively scheduled / "CONFIRMED" ;Indicates event is definite / "CANCELLED" ;Indicates event was canceled summary = "SUMMARY" [";" paramlist] ":" text CRLF transp = "TRANSP" [";" paramlist] ":" transvalue CRLF transvalue = "BUSY" ;Opaque/blocks on free/busy searches ;Default value is BUSY / "OUT" ;Opaque/blocks on free/busy searches / "PRIVATE" ;Opaque/blocks on free/busy searches / "CONFIDENTIAL" ;Opaque/blocks on free/busy searches / "TRANSPARENT" ;Transparent on free/time searches tzname = "TZNAME" [";" paramlist] ":" text CRLF tzoffset = "TZOFFSET" ":" utc-offset CRLF tztrans = "TZTRANS" ":" time CRLF url = "URL" ":" url CRLF uid = "UID" [";" paramlist] ":" text CRLF extension = "X-" [vendorid] word [";" paramlist] ":" value vendorid = 1*char "-" ;Vendor identification prefix text Dawson/Stenerson 64 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 ;End of grammar 6. Registration of Content Type Profiles This section defines procedures by which usage profiles for the MIME Calendaring and Scheduling Content Type are registered with the IANA and made available to the Internet community. Note that non-IANA profiles may be used by bilateral agreement, provided the associated profile names follow the "X-" convention defined above in section 3.1.6.33. The procedures defined here are designed to allow public comment and review of new profiles, while posing only a small impediment to the definition of new profiles. Registration of a new profile is accomplished by the following steps. 6.1 Define the profile A profile is defined by completing the following template. To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME profile XXX Profile name: Profile purpose: Profile type-subtype: Profile special notes (optional): Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) The explanation of what goes in each field in the template follows. Profile name: The name of the profile as it will be generally referred to in public. This name is required in the profile. Profile purpose: The purpose of the profile (e.g., to schedule document management updates, etc.). Give a short but clear description. This description is required in the profile. Profile type-subtype: The type-subtypes of the profile as they will appear in the text/calendar MIME Content-Type Profile parameter. This list of type-subtype values is required in the profile. Profile properties: The list of MIME Calendaring and Scheduling Content Type properties associated with the profile. This list of properties that are included in the profile. If a property is required by the profile, it should noted in this section. Other types not mentioned in the profile definition may also be present. Note Dawson/Stenerson 65 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 that any new properties referenced by the profile must be defined separately as described in section . Profile special notes: Any special notes about the profile, how it is to be used, etc. This section is not required in the profile. 6.2 Post the profile definition The profile description must be posted to the IETF Calendaring and Scheduling Working Group discussion list, ietf-calendar@imc.org. 6.3 Allow a comment period Discussion on the new profile must be allowed to take place on the list for a minimum of two weeks. Consensus must be reached on the profile before submitting the profile for approval. 6.4 Submit the profile for approval Once the two-week comment period has elapsed, and the proposer is convinced consensus has been reached on the profile, the registration application should be submitted to the Profile Reviewer for approval. The Profile Reviewer is appointed to the Application Area Directors and may either accept or reject the profile registration. An accepted registration should be passed on by the Profile Reviewer to the IANA for inclusion in the official IANA profile registry. The registration may be rejected for any of the following reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) Technical deficiencies raised on the list or elsewhere have not been addressed. The Profile Reviewer's decision to reject a profile may be appealed by the proposer to the IESG, or the objections raised can be addressed by the proposer and the profile resubmitted. 6.5 Profile Change Control Existing profiles may be changed using the same process by which they were registered. 1. Define the change 2. Post the change 3. Allow a comment period 4. Submit the profile for approval Note that the original author or any other interested party may propose a change to an existing profile, but that such changes should only be proposed when there are serious omissions or errors in the published specification. The Profile Reviewer may object to a change if it is not backwards compatible, but is not required to do so. Dawson/Stenerson 66 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Profile definitions can never be deleted from the IANA registry, but profiles which are no longer believed to be useful can be declared OBSOLETE by a change to their "intended use" field. 6.6 Registration of New Properties This section defines procedures by which new properties for the MIME Calendaring and Scheduling Content Type are registered with the IANA. Note that non-IANA properties may be used by bilateral agreement, provided the associated properties names follow the "X-" convention defined above in section 3.1.6.33. The procedures defined here are designed to allow public comment and review of new properties, while posing only a small impediment to the definition of new properties. Registration of a new property is accomplished by the following steps. 6.6.1 Define the property A property is defined by completing the following template. To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property XXX Property name: Property purpose: Property data type(s): Property encoding: Property special notes (optional): Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) The meaning of each field in the template is as follows. Property name: The name of the property, as it will appear in the body of an text/calendar MIME Content-Type "property: value" line to the left of the colon ":". Property purpose: The purpose of the property (e.g., to indicate a delegate for the event or to-do, etc.). Give a short but clear description. Property data type(s): Any of the valid data types for the property value needs to be specified. The default data type also needs to be specified. If a new data type is specified, it needs to be declared in this section. Dawson/Stenerson 67 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 Property encoding: The encodings permitted for the property value. This description must be precise and must not violate the general encoding rules defined in this document. Property special notes: Any special notes about the property, how it is to be used, etc. 6.6.2 Post the Property definition The property description must be posted to the new property discussion list, ietf-calendar@imc.org. 6.6.3 Allow a comment period Discussion on the new property must be allowed to take place on the list for a minimum of two weeks. Consensus must be reached on the property before proceeding to the next step. 6.6.4 Submit the property for approval Once the two-week comment period has elapsed, and the proposer is convinced consensus has been reached on the property, the registration application should be submitted to the Profile Reviewer for approval. The Profile Reviewer is appointed to the Application Area Directors and may either accept or reject the property registration. An accepted registration should be passed on by the Profile Reviewer to the IANA for inclusion in the official IANA profile registry. The registration may be rejected for any of the following reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) Technical deficiencies raised on the list or elsewhere have not been addressed. The Profile Reviewer's decision to reject a property may be appealed by the proposer to the IESG, or the objections raised can be addressed by the proposer and the property resubmitted. 6.7 Property Change Control Existing properties may be changed using the same process by which they were registered. 1. Define the change 2. Post the change 3. Allow a comment period 4. Submit the property for approval Note that the original author or any other interested party may propose a change to an existing property, but that such changes should only be proposed when there are serious omissions or errors in the published specification. The Profile Reviewer may object to a Dawson/Stenerson 68 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 change if it is not backwards compatible, but is not required to do so. Property definitions can never be deleted from the IANA registry, but properties which are no longer believed to be useful can be declared OBSOLETE by a change to their "intended use" field. 7. File extension The file extension of "vcs" is to be used to designate a file containing calendaring and scheduling information consistent with this MIME content type. 8. Macintosh File Type Code The file type code of "vcal" is to be used in Apple MacIntosh operating system environments to designate a file containing calendaring and scheduling information consistent with this MIME media type. 9. References The following document are referred to within this document. [ISO 8601] ISO 8601, "Data elements and interchange formats_ Information interchange_Representation of dates and times", International Organization for Standardization, June, 1988. This standard is also addressed by the Internet Draft document ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt. [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support Facilities_Registration Procedures for Public Text Owner Identifiers", Second Edition, International Organization for Standardization, April, 1991. [MIME DIR] Howes, T., Smith, M., "A MIME Content-Type for Directory Information", Internet-draft-ietf-asid-mime-direct-05.txt, March, 1997. [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC 1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC 1766] Alvestrand, H., "Tags for the Identification of Languages", March 1995. [RFC 1872] Levinson, E., "The MIME Multipart/Related Content-type," RFC 1872, December 1995. [RFC 2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Dawson/Stenerson 69 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 [RFC 2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. [RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC 2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048, January 1997. [US-ASCII] "Coded Character Set--7-bit American Standard Code for Information Interchange", ANSI X3.4-1986. [VCARD] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", http://www.versit.com/pdi/vcard-21.txt, September 18, 1996. [VCAL] Internet Mail Consortium, "vCalendar - The Electronic Calendaring and Scheduling Exchange Format", http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. [XAPIA] "XAPIA CSA, Calendaring and Scheduling Application Programming Interface (CSA) Version 1.0", X.400 API Association, November 15, 1994. 10. Acknowledgments A hearty thanks to the IETF Calendaring and Scheduling Working Group and also the following individuals who have participated in the drafting, review and discussion of this memo: Roland Alden, Harald T. Alvestrand, Denis Bigorgne, John Binici, Bill Bliss, Andre Courtemanche, Dave Crocker, Alec Dun, Ross Finlayson, Randell Flink, Ned Freed, Patrik Falstrom, Chuck Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Mark Horton, Bruce Kahn, C. Harald Koch, Theodore Lorek, Keith Moore, Cecil Murray, Chris Newman, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert Ripberger, Andras Salamar, Vinod Seraphin, Ken Shan, Andrew Shuman, William P. Spencer, Mark Towfiq, Robert Visnov, James L. Weiner, Mike Weston, William Wyatt, Steve Silverberg. 11. Author's Address The following address information is provided in a MIME-VCARD, Electronic Business Card, format. The authors of this draft are: BEGIN:VCARD FN:Frank Dawson ORG:Lotus Development Corporation ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive; Raleigh;NC;27613-3502;USA Dawson/Stenerson 70 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 TEL;WORK;MSG:+1-919-676-9515 TEL;WORK;FAX:+1-919-676-9564 EMAIL;INTERNET:fdawson@earthlink.net URL:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD FN:Derik Stenerson ORG:Microsoft Corporation ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;98052-6399;USA TEL;WORK;MSG:+1-206-936-5522 TEL;WORK;FAX:+1-206-936-7329 EMAIL;INTERNET:deriks@Exchange.Microsoft.com END:VCARD The iCalendar Object is a result of the work of the Internet Engineering Task Force Calendaring and Scheduling Working Group. The chairman of that working group is: BEGIN:VCARD FN:Anik Ganguly ORG:OnTime, Inc. ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern Highway; Southfield;MI;48075;USA TEL;WORK;MSG:+1-810-559-5955 TEL;WORK;FAX:+1-810-559-5034 EMAIL;INTERNET:anik@ontime.com END:VCARD 12. iCalendar Object Examples The following examples are provided as an informational source of illustrative iCalendar Objects consistent with this content type. The following is an example of a MIME message with a single body part consisting of a text/calendar content type. The message specifies a meeting request between the originator and recipient of the message. TO:jsmith@host1.com FROM:jdoe@host1.com MIME-VERSION:2.0 MESSAGE-ID:<19960704 08:30:00 EDT xyz@host1.com> CONTENT-TYPE:text/calendar;PROFILE=request,event BEGIN:VCALENDAR PROFILE:event-request VERSION:2.0 BEGIN:VEVENT DTSTART:19960918T143000Z DTEND:19960920T220000Z CATEGORIES:CONFERENCE;PROJECT Dawson/Stenerson 71 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 SUMMARY:Networld+Interop Conference DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Networld+Interop Conference= and Exhibit=0D=0A= Atlanta World Congress Center=0D=0A= Atlanta, Georgia END:VEVENT END:VCALENDAR The following example message issues a meeting request that does not require any reply. The message is sent as a singular "text/calendar" content type, body part. From: jsmith@host1.com To: ietf-calendar@imc.org Subject: First IETF-Calendar Working Group Meeting MIME-Version: 2.0 Message-ID: <id1@host1.com> Content-Type: text/calendar;Profile=event,request BEGIN:VCALENDAR PROFILE:event-request PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org DESCRIPTION:First IETF-Calendaring and Scheduling Working Group Meeting CATEGORIES:MEETING CLASS:PUBLIC CREATED:19961022T083000 SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19961210T210000Z DTEND:19961210T220000Z LOCATION:San Jose, CA - Fairmont Hotel UID:guid-1.host1.com END:VEVENT END:VCALENDAR The following is an example of a MIME message with a single body part consisting of a text/calendar content type. The message specifies a meeting request between the originator and recipient of the message. TO:jsmith@host1.com FROM:jdoe@host1.com MIME-VERSION:1.0 MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com> CONTENT-TYPE:text/calendar;PROFILE=event-request BEGIN:VCALENDAR PROFILE:event-request VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VEVENT SEQUENCE:0 Dawson/Stenerson 72 Expires September 1997 Internet Draft C&S Core Object Specification March 26, 1997 UID:19970324-080045-4000F192713-0052 ATTENDEE;EXPECT=REQUEST:jsmith@host1.com DTSTART:19970324T123000Z DTEND:19970324T210000Z CATEGORIES:CONFERENCE;PROJECT CLASS:PUBLIC SUMMARY:Calendaring Interop Conference DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Calendaring Interop= Conference and Exhibit=0D=0A= Atlanta, Georgia LOCATION:Atlanta World Congress Center ATTACH;VALUE=URL:file://xyzCorp.com/conf/bkgrnd.ps END:VEVENT END:VCALENDAR Example of a reply to the above request, accepting the meeting. TO:jdoe@host1.com FROM:jsmith@host1.com MIME-VERSION:1.0 MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com> CONTENT-TYPE:text/calendar;PROFILE=event-reply BEGIN:VCALENDAR PROFILE:event-reply VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VEVENT SEQUENCE:0 RESPONSE-SEQUENCE:0 UID:19970324-080045-4000F192713-0052 ATTENDEE;STATUS=CONFIRMED;EXPECT=REQUEST:jsmith@host1.com END:VEVENT END:VCALENDAR An example of a meeting cancelation: TO:jsmith@host1.com FROM:jdoe@host1.com MIME-VERSION:1.0 MESSAGE-ID:<19970322 08:30:00 EDT xyz@host1.com> CONTENT-TYPE:text/calendar;PROFILE=event-cancel BEGIN:VCALENDAR PROFILE:event-cancel VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VEVENT UID:19970324-080045-4000F192713-0052 END:VEVENT END:VCALENDAR Dawson/Stenerson 73 Expires September 1997