Network Working Group Frank Dawson, Lotus Internet Draft Derik Stenerson, Microsoft November 21, 1997 Expires May 1998 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Status of this Memo This memo is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups MAY 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 memo is unlimited. Copyright (C) The Internet Society 1997. All Rights Reserved. Abstract There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the a definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is ''TEXT/CALENDAR''. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event and to-do information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems or using HTTP. In addition, the content type is useful as an object Dawson/Stenerson 1 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information. In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification. This memo is based on the calendaring and scheduling model defined in []. The document is also the basis for the calendaring and scheduling interoperability protocol defined in [ITIP]. This memo also includes the format for defining iCalendar object methods. An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. Dawson/Stenerson 2 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 Table of Contents 1. Introduction........................................................5 2. Basic Grammar and Conventions.......................................5 2.1 Formatting Conventions ...........................................6 2.2 Related Memos ....................................................7 3. TEXT/CALENDAR Registration Information..............................7 4. iCalendar Object Specification......................................9 4.1 Content Considerations ...........................................9 4.1.1 Content Lines ................................................10 4.1.2 List and Field Separators ....................................12 4.1.3 Multiple Values ..............................................13 4.1.4 Binary Content ...............................................13 4.1.5 Property Parameters ..........................................13 4.1.6 Alternate Text Representation ................................14 4.1.7 Character Set ................................................14 4.1.8 Inline Encoding ..............................................15 4.1.9 Language .....................................................15 4.1.10 Value Data Types ............................................15 4.2 iCalendar object ................................................25 4.3 Property ........................................................26 4.4 Calendar Components .............................................26 4.4.1 Event Component ..............................................26 4.4.2 To-do Component ..............................................28 4.4.3 Journal Component ............................................29 4.4.4 Free/Busy Component ..........................................30 4.4.5 Alarm Component ..............................................31 4.4.6 Timezone Component ...........................................33 4.5 Calendar Properties .............................................37 4.5.1 Calendar Scale ...............................................37 4.5.2 Method .......................................................37 4.5.3 Product Identifier ...........................................38 4.5.4 Source .......................................................38 4.5.5 Source Name ..................................................39 4.5.6 Version ......................................................39 4.6 Component Properties ............................................40 4.6.1 Attachment ...................................................40 4.6.2 Attendee .....................................................40 4.6.3 Categories ...................................................43 4.6.4 Classification ...............................................44 4.6.5 Comment ......................................................44 4.6.6 Contact ......................................................45 4.6.7 Date/Time Completed ..........................................45 4.6.8 Date/Time Created ............................................46 4.6.9 Date/Time Due ................................................46 4.6.10 Date/Time End ...............................................46 4.6.11 Date/Time Stamp .............................................47 4.6.12 Date/Time Start .............................................47 4.6.13 Daylight ....................................................48 4.6.14 Description .................................................48 4.6.15 Duration ....................................................49 4.6.16 Exception Date/Times ........................................50 4.6.17 Exception Rule ..............................................50 Dawson/Stenerson 3 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.6.18 Free/Busy Time ..............................................51 4.6.19 Geographic Position .........................................52 4.6.20 Last Modified ...............................................53 4.6.21 Location ....................................................53 4.6.22 Percent Complete ............................................54 4.6.23 Priority ....................................................54 4.6.24 Recurrence Date/Times .......................................55 4.6.25 Recurrence ID ...............................................56 4.6.26 Recurrence Rule .............................................57 4.6.27 Related To ..................................................64 4.6.28 Repeat Count ................................................65 4.6.29 Request Status ..............................................66 4.6.30 Resources ...................................................67 4.6.31 Sequence Number .............................................68 4.6.32 Status ......................................................68 4.6.33 Summary .....................................................69 4.6.34 Time Transparency ...........................................69 4.6.35 Time Zone Name ..............................................70 4.6.36 Time Zone Offset ............................................70 4.6.37 Uniform Resource Locator ....................................70 4.6.38 Unique Identifier ...........................................71 4.6.39 Non-standard Properties .....................................72 5. Recommended Practices..............................................72 6. Registration of Content Type Elements..............................73 6.1 Registration of New and Modified iCalendar object Methods .......73 6.2 Registration of New Properties ..................................73 6.2.1 Define the property ..........................................73 6.2.2 Post the Property definition .................................74 6.2.3 Allow a comment period .......................................74 6.2.4 Submit the property for approval .............................74 6.3 Property Change Control .........................................75 7. File extension.....................................................75 8. Macintosh File Type Code...........................................75 9. References.........................................................75 10. Acknowledgments...................................................77 11. Author's Address..................................................77 12. iCalendar object Examples.........................................78 13. Full Copyright Statement..........................................80 Dawson/Stenerson 4 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 1. Introduction The use of calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. However, the longer term growth of calendaring and scheduling, is currently limited by the lack of Internet standards for the message content types that are central to these groupware applications. This memo is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications. This memo defines a MIME content type for exchanging electronic calendaring and scheduling information. The Internet Calendaring and Scheduling Core Object Specification, or iCalendar, allows for the capture and exchange of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager or a Group Scheduling product. The calendaring and scheduling model implemented by this memo is defined in the [ICMS]. The format is suitable as an exchange format between applications or systems. The format is defined in terms of a MIME content type. This will enable the object to be exchanged using several transports, including but not limited to SMTP, HTTP, a file system, desktop interactive protocols such as the use of a memory-based clipboard or drag/drop interactions, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport such as infrared might also be used. The definition of a calendaring and scheduling interoperability protocol is the subject of another memo [ITIP]. The memo also provides for the definition of iCalendar object methods that will map this content type to a set of messages for supporting calendaring and scheduling operations such as requesting, replying to, modifying, and canceling meetings or appointments, to-dos and journal entries. The iCalendar object methods can be used to define other calendaring and scheduling operations such a requesting for and replying with free/busy time data. The memo also includes a formal grammar for the content type to aid in the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. 2. Basic Grammar and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interoperated as described in [RFC 2119]. This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. Dawson/Stenerson 5 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 The notation used in this memo is the augmented BNF notation of [RFC 822]. Readers intending on implementing this format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric and hexadecimal values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case- insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information that is not essential to the building of a conformant implementation of the specifications of this memo. The information is provided to highlight a particular feature or characteristic of the specifications. The format for the iCalendar object is based on the syntax of the [MIME DIR] content type. While the iCalendar object is not a profile of the [MIME DIR] content type, it does reuse a number of the elements from the [MIME DIR] specification. 2.1 Formatting Conventions The mechanisms defined in this memo are defined in propose. In order to refer to elements of the calendaring and scheduling model [ICMS], core object (this memo) or interoperability protocol [ITIP] in this memo some formatting conventions have been used. Calendaring and scheduling roles defined by [ICMS] are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" within the scheduling protocol defined by [ITIP] Calendar components defined by this memo are referred to with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to the daily journal calendar component. Scheduling methods defined by [ITIP] are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified, "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component. The properties defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a calendar user. Property parameters defined by this memo are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Enumerated values defined by this memo are referred to with capitalized text, either alone or followed by the word "value". For example, the "MINUTELY" value can Dawson/Stenerson 6 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 be used with the "FREQ" component of the "RECUR" data type to specify repeating components based on an interval of one minute or more. 2.2 Related Memos Implementers will need to be familiar with several other memos that, along with this memo, form a framework for Internet calendaring and scheduling standards. This memo, [ICAL], specifies a core specification of objects, data types, properties and property parameters. [ICMS] - specifies a common terminology and abstract; [ITIP] - specifies an interoperability protocol for scheduling between different implementations; [IMIP] specifies an Internet email binding for [ITIP]; [IRIP] - specifies an Internet real time protocol binding for [ITIP]. This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts or definitions. 3. 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 memo is in no way limited solely as a MIME content type. The following text is intended to register this memo 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: method The "method" parameter is used to convey the iCalendar object method 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 to be used as a guide for 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 method definition specifically calls for this behavior. Unless specifically forbidden by a particular method definition, a text/calendar content type MAY contain any set of properties Dawson/Stenerson 7 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 permitted by the Calendaring and Scheduling Core Object Specification. The value for the "method" parameter is defined as follows: method = 1*(ALPHA / DIGIT / "-") ; IANA registered iCalendar object method Optional parameters: charset, component 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. The "component" parameter conveys the type of iCalendar calendar component within the body part. If the iCalendar object contains more than one calendar component, then the components are specified as a comma-separated list of values. The value for the "component" parameter is defined as follows: component = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" / x-name / iana-token Optional content header fields: Any header fields defined by [RFC 2045]. Encoding considerations: This MIME content type can contain 8bit characters, so the use of quoted-printable or base64 MIME content- transfer-encodings MAY be necessary when iCalendar objects are transferred across protocols restricted to the 7bit repertoire. Note that each property in the content entity MAY also have special characters encoded using a BACKSLASH character (ASCII decimal 92) escapement technique. This means that content values MAY end up encoded twice. Security considerations: SPOOFING - - In this memo, the "Organizer" is the only person authorized to make changes to an existing "VEVENT", "VTODO", "VJOURNAL" calendar component and redistribute the updates to the "Attendees". An iCalendar object that maliciously changes or cancels an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar component MAY be constructed by someone other than the "Organizer" and sent to the "Attendees". In addition in this memo, an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" calendar component is the only person authorized to update any parameter associated with their "ATTENDEE" property and send it to the "Organizer". An iCalendar object that maliciously changes the "ATTENDEE" parameters MAY be constructed by someone other than the real "Attendee" and sent to the "Organizer". PROCEDURAL ALARMS - - An iCalendar object can be created that contains a "VEVENT" and "VTODO" calendar component with an "VALARM" calendar components. The "VALARM" calendar component MAY be of type PROCEDURE and MAY have an attachment containing some sort of Dawson/Stenerson 8 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 executable program. Implementations that incorporate these types of alarms are subject to any virus or malicious attack that MAY occur as a result of executing the attachment. ATTACHMENTS - - An iCalendar object MAY include references to Uniform Resource Locators that MAY be programmed resources. Implementers and users of this memo should be aware of the network security implications of accepting and parsing such information. In addition, the security considerations observed by implementations of electronic mail systems should be followed for this memo. Interoperability considerations: This MIME content type is intended to define a common format for conveying calendaring and scheduling information between different systems. It is heavily based on the earlier [VCAL] industry specification. Intended Usage: COMMON Published specification: This memo. Author/Change controllers: Frank Dawson 6544 Battleford Drive Raleigh, NC 27613-3502 919-676-9515 (Telephone) 919-676-9564 (Data/Facsimile) Frank_Dawson@Lotus.com (Internet Mail) Derik Stenerson One Microsoft Way Redmond, WA 98052-6399 425-936-5522 (Telephone) 425-936-7329 (Facsimile) deriks@microsoft.com (Internet Mail) 4. iCalendar Object Specification The following sections define the details of a Calendaring and Scheduling Core Object Specification. 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 memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. 4.1 Content Considerations The iCalendar object consists of lines of text. This section defines how the content lines MUST be formatted. Dawson/Stenerson 9 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.1.1 Content Lines The iCalendar object consists of individual lines of text, delimited by a line break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII decimal 10). Lines of text should not be longer than 76 characters, excluding the line break. Long lines of text can be split into a multiple line representations using a line "folding" technique. That is, a long line MAY be split at any point by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, ASCII decimal 32 or HTAB, ASCII decimal 9). Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. For example the line: DESCRIPTION:This is a long description that exists on a long line. Can be represented as: DESCRIPTION:This is a long description that exists on a long line. The process of moving from this folded multiple line representation to its single line representation is called "unfolding". Unfolding is accomplished by removing the CRLF character and the linear white space character that immediately follows. An intentional formatted text line break MAY only be included in a property value by representing the line break with the character sequence of BACKSLASH (ASCII decimal 92), followed by a LATIN SMALL LETTER N (ASCII decimal 110) or a LATIN CAPITAL LETTER N (ASCII decimal 78), that is "\n" or "\N". For example a multiple line "DESCRIPTION" property value of: Project XYZ Final Review Conference Room - 3B Come Prepared. Could be represented as: DESCRIPTION:Project_XYZ Final_Review\n Conference Room - 3B\nCome_Prepared. The content information associated with an iCalendar object is formatted using a syntax similar to that defined by [MIME DIR]. That is, the content information consists of one or more CRLF-separated content lines as defined by the following notation: contentline = name *(";" [WSP] param ) ":" [WSP] value-list CRLF ; Lines longer than 75 characters should be folded Dawson/Stenerson 10 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 name = iana-token / x-name x-name = "X-" 1*(ALPHA / DIGIT / "-") ;Reservered for experimental use. param = param-name "=" param-value *("," param-value) param-name = iana-token param-value = quoted-string / text value-list = value-struct *([FOLD] "," value-struct) ; permitted values are restricted by valuetype value-struct = value-elem *([FOLD] ";" value-elem) value-elem = folded-text / folded-b ; encoding determined by encoding parameter iana-token = 1*(ALPHA / DIGIT / "-") ; iCalendar identifier registered with IANA text = *SAFE-CHAR quoted-string = DQUOTE *(QSAFE-CHAR / QUOTED-CHAR) DQUOTE folded-text = *([FOLD] (SAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)) folded-base64 = *([FOLD] 4B-CHAR) [[FOLD] b-end] base64-end = (2B-CHAR "==") / (3B-CHAR "=") ESCAPED-CHAR = "\" ("\" / DQUOTE / ";" / "," / "N" / "n") ; \\ encodes \, \" encodes ", \N or \n encodes newline ; \; encodes ;, \, encodes , B-CHAR = ALPHA / DIGIT / "+" / "/" FOLD = CRLF WSP ; not considered part of the value NON-ASCII = %x80-FF ; use restricted by charset parameter ; on outer MIME object QSAFE-CHAR = %x20-21 / %x23-5B / %x5D-7E / NON-ASCII ; Any character except CTLs, DQUOTE, or "\" QUOTED-CHAR = "\" ("\" / DQUOTE) ; \\ encodes \, \" encodes " SAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B %x5D-7E / NON-ASCII ; Any character except CTLs, DQUOTE, ";", ":", "\", "," Dawson/Stenerson 11 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z BIT = "0" / "1" CHAR = %x01-7F ; any 7-bit US-ASCII character, excluding NUL CR = %x0D ; carriage return CRLF = CR LF ; Internet standard newline CTL = %x00-1F / %x7F ; controls DIGIT = %x30-39 ; 0-9DQUOTE = %x22 WSP = SPACE / HTAB SPACE = %x20 HTAB = %x09 4.1.2 List and Field Separators List of values MAY be specified for property values or property parameter values. Each value in a list of values MUST be separated by a COMMA character (ASCII decimal 44). Some property values are defined in terms of multiple components. These structured property values MUST have their components separated by a SEMICOLON character (ASCII decimal 59). Lists of property parameters MAY be specified for a property. Each property parameter in a list of property parameters MUST be separated by a SEMICOLON character (ASCII decimal 59). A COLON character in a property value does not need to be escaped with a BACKSLASH character. A BACKSLASH character (ASCII decimal 92) in a property value MUST be escaped with another BACKSLASH character. A COMMA character in a property value MUST be escaped with a BACKSLASH character (ASCII decimal 92). A SEMICOLON character in a property value MUST be escaped with a BACKSLASH character (ASCII decimal 92). Property parameters with values containing a COLON, a SEMICOLON or a COMMA character must be placed in quoted text string. 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. Dawson/Stenerson 12 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 ATTENDEE;RSVP=TRUE;ROLE=ATTENDEE:MAILTO:J.Smith RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 4.1.3 Multiple Values Each 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 character (ASCII decimal 44). 4.1.4 Binary Content Binary content information in an iCalendar object SHOULD be referenced using a URI within a property value. That is the binary content information SHOULD be placed in an external MIME entity that can be referenced by a URI from within the iCalendar object. In addition, binary content information MAY be included within an iCalendar object, but only after first encoding it into text using the "B" encoding method defined in [RFC 2047]. Support for inline binary content SHOULD be restricted to those applications requirements that necessitate conveying the complete calendaring and scheduling information within a single iCalendar object. A property containing inline binary content information MUST specify the "ENCODING" property parameter. Binary content information placed external to the iCalendar object MUST be referenced by a uniform resource identifier (URI). The following example specifies an "ATTACH" property that references an attachment external to the iCalendar object with a URI reference: ATTACH:http://xyz.com/public/quarterly-report.doc The following example specifies an "ATTACH" property with inline binary encoded content information: ATTACH;ENCODING=b;VALUE=text:MIICajCCAdOgAwIBAgICBEUwDQYJKoZI hvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENv bW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlv biBTeXN0 <...remainder of "B" encoded binary data...> 4.1.5 Property Parameters A property MAY have additional attributes associated with it. These "property parameters" contain meta information about the property or the property value. Property parameters MAY be used to specify the location of an alternate text representation for a property value, the language of a text property value or the data type of the property value. Dawson/Stenerson 13 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 Property parameter values that contain the COLON, SEMICOLON, COMMA or BACKSLASH character separators MUST be specified as quoted-string text values. For example: DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards Conference - - Las Vegas, NV, USA The general property parameters defined by this memo are specified the following notation: parameter = altrepparm ;Alternate text representation / encodingparm ;Inline encoding / languageparm ;Text language / valuetypeparm ;Property value data type 4.1.6 Alternate Text Representation The "ALTREP" property parameter is an OPTIONAL property parameter. It specifies the URI that points to an alternate representation for a textual property value. The property MUST include a value that reflects the default representation. This property parameter MAY include multiple values, separated by the COMMA character (ASCII decimal 44). The property parameter MAY only be specified in the "COMMENT", "CONTACT", "DESCRIPTION", "LOCATION" and "SUMMARY" properties. For example: DESCRIPTION;ALTREP="CID:":Project XYZ Review Meeting will include the following agenda items: (a) Market Overview, (b) Finances, (c) Project Management The "ALTREP" property parameter value might point to a "text/html" content portion. Content-Type:text/html Content-Id:

Project XYZ Review Meeting will include the following agenda items:

  • Market Overview
  • Finances
  • Project Management

    • The "ALTREP" property parameter is defined by the following notation: altrepparm = "altrep" "=" uri 4.1.7 Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is [UTF-8]. The "charset" Content-Type parameter MAY be used in MIME transports to specify any other IANA registered character set. Dawson/Stenerson 14 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.1.8 Inline Encoding The "ENCODING property parameter is an OPTIONAL property parameter. It identifies the inline encoding used in a property value. The default encoding type is "8bit", corresponding to a property value consisting of text. The "b" encoding type corresponds to a property value encoded using the "B" encoding defined in [RFC 2047]. The "ENCODING" property parameter is defined by the following notation: encodingparam = "encoding" "=" "8bit" / "b" / iana-token / x-name ;"8bit" text encoding is defined in [RFC 2045] ;"b" binary encoding format is defined in [RFC 2047] ;Some other IANA registered iCalendar encoding type ;A non-standard, experimental encoding type 4.1.9 Language The "LANGUAGE" property parameter is an OPTIONAL property parameter. It identifies the language used in text values. 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. The "LANGUAGE" property parameter is defined by the following notation: languageparm = "language" "=" language language = 4.1.10 Value 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 values of a property MUST be of a single data type. For example, a "RDATE" property cannot have a combination of DATE-TIME and TIME values. The "VALUE" property parameter is defined by the following notation: valuetypeparm = "value" "=" valuetype valuetype = "boolean" / "cal-address" / "date" / "date-time" / "duration" / "float" / "integer" Dawson/Stenerson 15 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 / "period" / "recur" / "text" / "time" / "uri" / "utc-offset" / x-name ;Some experimental iCalendar data type. / iana-token ;Some other IANA registered iCalendar data type. The following data types are defined by this memo. 4.1.10.1 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 4.1.10.2 Calendar User Address The "CAL-ADDRESS" data type is used to identify properties that contain an address of a calendar user. The value is a URI as defined by [RFC 1738] or any other IANA registered form for a URI. When used to address an Internet email transport address for a calendar user, the value MUST be a MAILTO URI, as defined by [RFC 1738]. The data type is as defined by the following notation: cal-address = uri 4.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: date-fullyear = 4DIGIT date-month = 2DIGIT ;01-12 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 ;based on month/year date = date-fullyear date-month date-mday Dawson/Stenerson 16 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 For example, the following represents July 14, 1997: 19970714 4.1.10.4 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 below. 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 (four hours behind UTC in DST), expressed as a local time and local time with UTC offset: 19970714T133000Z 19970714T083000 19970714T083000-0400 4.1.10.5 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: 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: P10Y3M15DT5H30M20S 4.1.10.6 Float The "FLOAT" data type is used to identify properties that contain a real value number value. If the property permits, multiple "float" Dawson/Stenerson 17 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 values MAY be specified using a COMMA character (ASCII decimal 44) separator character. The data type is defined by the following notation: float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] For example: 1000000.0000001 1.333 -3.14 4.1.10.7 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: integer = (["+"] / "-") *DIGIT For example: 1234567890 -1234567890 +1234567890 432109876 4.1.10.8 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's start and it's 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/PT5H30M Dawson/Stenerson 18 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 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 4.1.10.9 Recurrence Rule The "RECUR" data type is used to identify properties that contain a recurrence rule specification. The data type is a structured value consisting of a list of one or more recurrence grammar components. Each component is defined by a NAME=VALUE pair. The components are separated from each other by the SEMICOLON character (ASCII decimal 59). The components are not ordered in any particular sequence. Individual components MAY only be specified once. The FREQ component identifies the type of recurrence rule. This component MUST be specified in the recurrence rule. Valid values include SECONDLY, to specify repeating events based on an interval of a second or more; MINUTELY, to specify repeating events based on an interval of a minute or more; 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 INTERVAL component contains a positive integer representing how often the recurrence rule repeats. The default value is "1" or every minute for a MINUTELY rule, every hour for a HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule and every year for a YEARLY rule. The UNTIL component defines a date-time value which bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this date-time becomes the last instance of the recurrence. If not present, and the COUNT component is also not present, the RRULE is considered to repeat forever. The COUNT component defines the number of occurrences at which to range-bound the recurrence. This component is ignored if the "UNTIL" component is also present. The BYSECOND component specifies a COMMA character (ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 60. Dawson/Stenerson 19 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 Zero is the beginning of the minute and 60 is the beginning of the next minute. The BYMINUTE component specifies a COMMA character (ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 60. Zero is the beginning of the hour and 60 is the beginning of the next hour. The BYHOUR component specifies a COMMA character (ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 24. Zero is the start of the day and 24 is the start of the next day. The BYDAY component 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 BYDAY value MAY also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY RRULE. For example, within a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a MONTHLY rule, MO represents all Mondays within the month. The BYMONTHDAY component specifies a COMMA character (ASCII decimal 44) separated list of days of the month. Valid values are 1 to 31 or -31 to -1. Each BYMONTHDAY value MAY include a postive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day of the month within the MONTHLY rule. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a MONTHLY rule, -10 represents the tenth to the last day of the month. The BYYEARDAY component specifies a COMMA character (ASCII decimal 44) separated list of days of the year. Valid values are 1 to 366 or -366 to -1. For example, -1 represents the last day of the year (December 31st). The BYWEEKNO component specifies a comma-separated list of weeks of the year. Valid values are 1 to 53. This corresponds to weeks according to week numbering as defined in [ISO 8601]. That is, a week as "A seven day period within a calendar year, starting on a Monday and identified by its ordinal number within the year; the first calendar week of the year is the one that includes the first Thursday of that year." This component is only valid for YEARLY rules. Each BYWEEKNO value MAY include a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific week of the year within the YEARLY rule. If an integer modifier is not present, it means all days of this type within the Dawson/Stenerson 20 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 specified frequency. For example, within a YEARLY rule, 3 represents the third week of the year. The BYMONTH component specifies a comma separated list of months of the year. Valid values are 1 to 12. The WKST component specifies the day on which the workweek starts. Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant when a WEEKLY RRULE has an interval greater than 1, and a BYDAY component is specified. The default value is MO. The BYSETPOS component specifies a COMMA character (ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of events specified by the rule. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another Byxxx component. For example "the last work day of the month" could be represented as: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 Each BYSETPOS value MAY include a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific occurrence within the set of events specified by the rule. If BYxxx component values are found which are beyond the available scope (ie, BYMONTHDAY=30 in February), they are simply ignored. Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time (DTSTART) entry attribute. For example, "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month or a time. This information would be the same as what is specified for DTSTART. BYxxx components modify the recurrence in some manner. BYxxx components for a period of time which is the same or greater than the frequency generally reduce or limit the number of occurrences of the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the number of recurrence instances from all days (if BYMONTH tag is not present) to all days in January. BYxxx components for a period of time less than the frequency generally increase or expand the number of occurrences of the recurrence. For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. If only one BYxxx component is specified in the recurrence rule, the list of "n" unique values would cause "n" occurrences of the recurrence within each specified frequency interval, where each unique list value is substituted in the appropriate date position within DTSTART for each such occurrence. If multiple BYxxx components are specified, then the list of "n" unique values for each lower frequency BYxxx components is applied to the list of "n" unique values for higher frequency BYxxx components. Dawson/Stenerson 21 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 This process will not always increase the set of occurrences. If a higher component is inconsistent with what was generated for lower components, it would reduce the set. The ordering of BYxxx components from lower frequency to higher frequency is as follows: BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, BYYEARDAY, BYWEEKNO, BYMONTH, BYSETPOS. Here is an example of evaluating multiple BYxxx components. "FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;BYMINUTE=30" would first apply the "BYMINUTE=30" To "BYHOUR=8,9" to arrive at "every 8:30AM and 9:30AM". This in turn would be applied to "BYDAY=SU" to arrive at "every Sunday at 8:30AM and 9:30AM". This would be applied to "BYMONTH=1" to arrive at "every Sunday in January at 8:30AM and 9:30AM". Considering the FREQUENCY and INTERVAL, this would become "Every Sunday in January at 8:30AM and 9:30AM, every other year". If the BYMINUTE, BYDAY, BYMONTHDAY, BYYEARDAY, BYHOUR or BYMONTH component was missing, the appropriate mintues, hour, day or month would have been retrieved from DTSTART. The data type is defined by the following notation: recur = "FREQ"=freq ";" [("UNTIL" "=" enddate ";") / ("COUNT" "=" 1*DIGIT ";")] ["INTERVAL" "=" 1*DIGIT ";"] ["BYSECOND" "=" byseclist ";"] ["BYMINUTE" "=" byminlist ";"] ["BYHOUR" "=" byhrlist ";"] ["BYDAY" "=" bywdaylist ";"] ["BYMONTHDAY" "=" bymodaylist ";"] ["BYYEARDAY" "=" byyrdaylist ";"] ["BYWEEKNO" "=" bywknolist ";"] ["BYMONTH" "=" bymolist ";"] ["BYSETPOS" "=" bysplist ";"] ["WKST" "=" weekday ";")] *("X-" word "=" word) ";" ;Individual components MAY only be specified once. ;Rule components need not be specified in particular any order. freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" / "WEEKLY" / "MONTHLY" / "YEARLY" enddate = date ;A UTC value byseclist = seconds / ( seconds *("," seconds) ) seconds = 1DIGIT / 2DIGIT ;0 to 60 byminlist = minutes / ( minutes *("," minutes) ) minutes = 1DIGIT / 2DIGIT ;0 to 60 byhrlist = hour / ( hour *("," hour) ) Dawson/Stenerson 22 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 hour = 1DIGIT / 2DIGIT ;0 to 24 bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) ) weekdaynum = [([plus] ordwk / minus ordwk)] weekday plus = "+" minus = "-" ordwk = 1DIGIT / 2DIGIT ;1 to 53 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, ;FRIDAY, SATURDAY and SUNDAY days of the week. bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) ) monthdaynum = ([plus] ordmoday) / (minus ordmoday) ordmoday = 1DIGIT / 2DIGIT ;1 to 31 byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) ) yeardaynum = ([plus] ordyrday) / (minus ordyrday) ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366 bywknolist = weeknum / ( weeknum *("," weeknum) ) weeknum = ([plus] ordwk) / (minus ordwk) bymolist = monthnum / ( monthnum *("," monthnum) ) monthnum = 1DIGIT / 2DIGIT ;1 to 12 bysplist = setposday / ( setposday *("," setposday) ) setposday = yeardaynum For example, the following is a rule which specifies 10 meetings which occur every other day: FREQ=DAILY;COUNT=10;INTERVAL=2 There are other examples specified in the "RRULE" specification. 4.1.10.10 Text The "TEXT" data type is used to identify values that contain human readable text. The character set and language in which the text is represented is controlled by the "LANGUAGE" property parameters. The data type is defined by the ABNF for "text" in section 4.1.1. Dawson/Stenerson 23 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.1.10.11 Time The "TIME" data type is used to identify values that contain a time of day. The format is expressed as the [ISO 8601] complete representation, basic format for a time of day. The text format consists of a two-digit 24-hour of the day (i.e., values 0-23), two- digit minute in the hour (i.e., values 0-59), and two-digit seconds in the minute (i.e., values 0-59). If seconds of the minute are not supported by an implementation, then a value of "00" should be specified for the seconds component. Fractions of an hour, minute or second are not supported by this format. This format is used to represent local time, local time with UTC offset and UTC time. UTC time is identified by a LATIN CAPITAL LETTER Z suffix character (ASCII decimal 90), the UTC designator, appended to the time. The local time with UTC offset is expressed as a local time, suffixed with the signed offset from UTC. The UTC offset is express as the 2- digit hours and 2-digit minutes difference from UTC. It is expressed as positive, with a 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: time-hour = 2DIGIT ;00-23 time-minute = 2DIGIT ;00-59 time-second = 2DIGIT ;00-60 ;The "60" value is used to account for years with "leap" seconds. time-numzone = ("+" / "-") time-hour time-minute time-zone = "Z" / time-numzone time = time-hour time-minute time-second [time-zone] For example, the following represents 8:30 AM in New York, five hours behind UTC, in local time and local time with UTC offset. In addition, 1:30 PM in UTC is illustrated: 083000 083000-0500 133000Z There are cases when a floating time is intended within a property value. For example, an event MAY be defined that indicates that an individual will be busy from 11:00 AM to 1:00 PM every day. In these cases, a local time MAY 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 "VTIMEZONE" calendar component MUST be specified. Dawson/Stenerson 24 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.1.10.12 URI The "URI" data type is used to identify values that contain a uniform resource identifier (URI) 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 URI value formats in RFC 1738, RFC 2111 and any other IETF registered value format MAY be specified. The data type is defined by the following notation: uri = Any IANA registered URI format MAY be used. These include, but are not limited to, those defined in RFC 1738 and RFC 2111. For example, the following is a URI for a network file: http://host1.com/my-report.txt 4.1.10.13 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 The PLUS SIGN character MUST be specified for positive UTC offsets. For example, the following are UTC offsets are given for standard time for New York (five hours behind UTC) and Geneva (one hour ahead of UTC): -0500 +0100 4.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 an iCalendar object is as follows: icalobject = "BEGIN" ":" [WSP] "VCALENDAR" CRLF icalbody "END" ":" [WSP] "VCALENDAR" CRLF [icalobject] Dawson/Stenerson 25 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 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 SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR 4.3 Property A property is the definition of an individual attribute describing a calendar property or a calendar component. A property takes the form defined by the "contentline" notation defined in section 4.1.1. The following is an example of a property: DTSTART:19960415T083000-05:00 This memo places no imposed ordering of properties within an iCalendar object. Property names, parameter names and parameter values (i.e., everything to the left of the ":" on a line) are case insensitive. For example, the property name "DUE" is the same as "due" and "Due". 4.4 Calendar Components The body of the iCalendar object consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that with a particular calendar semantic. For example, the calendar component MAY specify a an event, a to-do, journal entry, time zone information, or free/busy time information, or alarm. The body of the iCalenar Object is defined by the following notation: icalbody = calprops 1*component calprops = [calscale] prodid method [source] [name] version component = 1*(eventc / todoc / journalc / freebusyc / / timezonec) 4.4.1 Event Component A "VEVENT" calendar component is a grouping of component properties and an OPTIONAL "VALARM" calendar component that represent a scheduled amount of time on a calendar. For example, it MAY be an activity; such as a one-hour, department meeting from 8:00 AM to 9:00 Dawson/Stenerson 26 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 AM, tomorrow. Generally, these events will take up time on an individual calendar. Hence, the event will appear as an opaque interval in a search for busy time. Alternately, the event MAY have its Time Transparency set to "TRANSPARENT" in order to prevent blocking of the event in searches for busy time. The "VEVENT" is also the calendar component used to specify an anniversary or daily reminder within a calendar. These events have a DATE value type for the "DTSTART" and "DTEND" properties instead of the default data type of DATE-TIME. If such a "VEVENT" has an end time, it MUST be specified as a DATE value also. The anniversary type of "VEVENT" MAY span more than one date (i.e, "DTEND" property value is set to a calendar date after the "DTSTART" property value). The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE data type but no "DTEND" property, the events non-inclusive end is the end of the calendar date specified by the "DTSTART" property. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME data type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. A "VEVENT" calendar component is defined by the following notation: eventc = "BEGIN" ":" [WSP] "VEVENT" CRLF eventprop *alarmc "END" ":" [WSP] "VEVENT" CRLF eventprop = *attach *attendee *categories [class] *comment *contact [created] [description] [dtend / duration] dtstart *exdate *exrule [geo] [last-mod] [location] [priority] [rstatus] [related] *resources *rdate *rrule dtstamp [seq] [status] summary [transp] uid [url] [recurid] The "VEVENT" calendar component cannot be nested within another calendar component. The "VEVENT" calendar components MAY be related to each other or to a "VTODO" or "VJOURNAL" calendar component with the "RELATED-TO" property. The following is an example of the "VEVENT" calendar component used to represent a meeting that will also be opaque to searches for busy time: BEGIN:VEVENT UID:19970901T130000Z-123401@host.com DTSTAMP:19970901T1300Z DTSTART:19970903T083000-0800 DTEND:19970903T110000-0800 SUMMARY:Annual Employee Review Dawson/Stenerson 27 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 CLASS:PRIVATE CATEGORIES:BUSINESS,HUMAN RESOURCES END:VEVENT The following is an example of the "VEVENT" calendar component used to represent a reminder that will not be opaque, but rather transparent, to searches for busy time: BEGIN:VEVENT UID:19970901T130000Z-123402@host.com DTSTAMP:19970901T1300Z DTSTART:19970401T083000-0800 DTEND:19970401T170000-0800 SUMMARY:Laurel is in sensitivity awareness class. CLASS:PUBLIC CATEGORIES:BUSINESS,HUMAN RESOURCES TRANSP:TRANSPARENT END:VEVENT The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates: BEGIN:VEVENT UID:19970901T130000Z-123403@host.com DTSTAMP:19970901T1300Z DTSTART:19971102 SUMMARY:Our Blissful Anniversary CLASS:CONFIDENTIAL CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION RRULE:FREQ=YEARLY END:VEVENT 4.4.2 To-do Component A "VTODO" calendar component is a grouping of component properties and an OPTIONAL "VALARM" 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 "VTODO" calendar component is defined by the following notation: todoc = "BEGIN" ":" [WSP] "VTODO" CRLF todoprop *alarmc "END" ":" [WSP] "VTODO" CRLF todoprop = *attach *attendee *categories [class] *comment [completed] *contact [created] [description] dtstamp dtstart [due / duration] *exdate *exrule [geo] [last-mod] [location] [percent] priority [rstatus] [related] *resources *rdate *rrule [recurid] [seq] [status] summary uid [url] Dawson/Stenerson 28 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 The "VTODO" calendar component cannot be nested within another calendar component. If "VTODO" calendar components need to be related to each other or to a "VTODO" or "VJOURNAL" calendar component, they can specify a relationship with the "RELATED-TO" property. The following is an example of a "VTODO" calendar component: BEGIN:VTODO UID:19970901T130000Z-123404@host.com DTSTAMP:19970901T1300Z DTSTART:19970415T083000-0500 DUE:19970415T235959-0500 SUMMARY:1996 Income Tax Preparation CLASS:CONFIDENTIAL CATEGORIES:FAMILY,FINANCE PRIORITY:1 STATUS:NEEDS-ACTION END:VEVENT 4.4.3 Journal Component A "VJOURNAL" calendar component is a grouping of component properties that represent one or more descriptive text notes on a particular calendar date. The "DTSTART" property is used to specify the calendar date that the journal entry is associated with. Generally, it will have a DATE value data type, but it MAY also be used to specify a DATE-TIME value data type. Examples of a journal entry include a daily record of a legislative body or a journal entry of individual telephone contacts for the day or an ordered list of accomplishments for the day. The calendar component can also be used to associate a document with a calendar date. The "VJOURNAL" calendar component does not take up time on a calendar. Hence, it does not play a role in free or busy time searches - - it is as though it has a time transparency value of TRANSPARENT. It is transparent to any such searches. A "VJOURNAL" calendar component is defined by the following notation: journalc = "BEGIN" ":" [WSP] "VJOURNAL" CRLF jourprop "END" ":" [WSP] "VJOURNAL" CRLF jourprop = *attach *attendee *categories [class] *comment *contact [created] [description] dtstart dtstamp *exdate *exrule [last-mod] [related] *rdate *rrule [rstatus] [seq] summary uid [url] [recurid] The "VJOURNAL" calendar component cannot be nested within another calendar component. If "VJOURNAL" calendar components need to be related to each other or to a "VEVENT" or "VTODO" calendar component, they can specify a relationship with the "RELATED-TO" property. The following is an example of the "VJOURNAL" calendar component: Dawson/Stenerson 29 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 BEGIN:VJOURNAL UID:19970901T130000Z-123405@host.com DTSTAMP:19970901T1300Z DTSTART;VALUE=DATE:19970317 SUMMARY:Staff meeting minutes 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 4.4.4 Free/Busy Component A "VFREEBUSY" calendar component is a grouping of component properties that represents either a request for, or a reply with, free or busy time information. Typically, this component exists in an iCalendar object that is being used to either request or return free or busy time information. A "VFREEBUSY" calendar component is defined by the following notation: freebusyc = "BEGIN" ":" [WSP] "VFREEBUSY" CRLF fbprop "END" ":" [WSP] "VFREEBUSY" CRLF fbprop = fbrequest / fbreply fbrequest = 1*attendee dtstart dtend [duration] *comment dtstamp [last-mod] *related [seq] uid ;This set of properties is used for free/busy time request. fbreply = 1*attendee [created] *comment [dtstart dtend] dtstamp *freebusy [last-mod] [related] [rstatus] [seq] uid [url] ;This set of properties is used for free/busy time reply. The "VFREEBUSY" calendar component cannot be nested within another calendar component. The "VFREEBUSY" calendar components MAY be related to each other with the "RELATED-TO" property. Multiple "VFREEBUSY" calendar components MAY be specified within a iCalendar object. This permits the grouping of Free/Busy information into logical collections, such as monthly groups of busy time information. The "VFREEBUSY" calendar component is intended for use in iCalendar object methods involving requests for free time, requests for busy time, requests for both free and busy, and the associated replies. Free/Busy information can be expressed using the "FREEBBUSY" property. This property provides a terse representation of time Dawson/Stenerson 30 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 periods. One or more "FREEBUSY" properties MAY be specified in the "VFREEBUSY" 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 all of the Free/Busy information in the "VFREEBUSY" calendar component. When present in a "VFREEBUSY" 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 "VFREEBUSY" calendar component. Any recurring events are resolved into their individual busy time periods using the "FREEBUSY" property. The following is an example of a "VFREEBUSY" calendar component used to request free or busy time information: BEGIN:VFREEBUSY ATTENDEE;ROLE=ORGANIZER:MAILTO:jane_doe@host1.com ATTENDEE:MAILTO:john_public@host2.com DTSTART:19971015T050000Z DTEND:19971016T050000Z DTSTAMP:19970901T083000Z SEQUENCE:0 UID:19970901T0830000-uid1@host1.com END:VFREEBUSY The following is an example of a "VFREEBUSY" calendar component used to reply to the request with busy time information: BEGIN:VFREEBUSY ATTENDEE:MAILTO:john_public@host2.com DTSTAMP:19970901T100000Z SEQUENCE:0 UID:19970901T0830000-uid1@host1.com FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M URL:http://host2.com/pub/busy/jpublic-01.vcs COMMENT:This iCalendar file contains busy time information for the next three months. END:VFREEBUSY 4.4.5 Alarm Component A "VALARM" calendar component is a grouping of component properties that is a reminder or alarm for an event or a to-do. The "VALARM" calendar component MAY only be specified in a "VEVENT" or "VTODO" calendar component. For example, it MAY define a reminder for a pending event or an overdue to-do. The "DTSTART" property specifies the calendar date and time of day that the alarm will be triggered. The value MAY alternately be set to Dawson/Stenerson 31 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 a DURATION, before or after the event or to-do, that the alarm will be triggered. A "VALARM" calendar component is defined by the following notation: alarmc = "BEGIN" ":" [WSP] "VALARM" CRLF alarmprop "END" ":" [WSP] "VALARM" CRLF alarmprop = *attendee *attach 1*categories *comment [description] dtstart duration *related repeat [summary] The "VALARM" calendar component can only appear within either a "VEVENT" or "VTODO" calendar component. The "VALARM" calendar components cannot be nested. The "CATEGORIES" property within the "VALARM" calendar component specifies the type or combination of types of the alarm. The "CATEGORIES" property value of AUDIO specifies an alarm that triggers with an audio sound; a value of DISPLAY specifies an alarm that triggers with the "Calendar User Agent" displaying text; the value of EMAIL specifies an alarm that triggers the posting of an electronic email message to one or more email addresses; and the value of PROCEDURE specifies an alarm that triggers the execution of a procedure. In an AUDIO category of alarm, the first "ATTACH" property in the "VALARM" calendar component that specifies an audio sound file is intended to be rendered as the alarm effect. If an "ATTACH" property is specified that does not refer to an audio sound file, then it is not used by this category of alarm. In addition, any "ATTENDEE", "DESCRIPTION" or "SUMMARY" properties are not used by this category of alarm. In a DISPLAY category of alarm, the "SUMMARY" property in the "VALARM" calendar component is intended to be displayed as the alarm effect. Any "ATTACH", "ATTENDEE" or "DESCRIPTION" properties in the "VALARM" calendar component are not used by this category of alarm. In an EMAIL category of alarm, the intended alarm effect is to use the "DESCRIPTION" property in the "VALARM" calendar component as the body text of an email message that is to be sent to the addresses specified by any "ATTENDEE" properties present in the "VALARM" calendar component. The "SUMMARY" property in the "VALARM" calendar component is intended to be used as the subject text for the email. Any "ATTACH" properties are not used by this category of alarm. In a PROCEDURE category of alarm, the first "ATTACH" property in the "VALARM" calendar component that specifies a procedure or program is intended to be invoked as the alarm effect. Any "ATTACH" properties that do not refer to a procedure or program, then it is not used by this category of alarm. In addition, the "ATTENDEE", "DESCRIPTION" and "SUMMARY" properties are not used by this category of alarm. "Calendar User Agents" that receive an iCalendar object with this Dawson/Stenerson 32 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 category of alarm, should allow the "Calendar User" to disable or otherwise ignore this category of alarm. While a very useful alarm capability, the PROCEDURE category of alarm should be treated by the "Calendar User Agent" as a potential security risk. The following is an example of the "VALARM" calendar component: BEGIN:VALARM DTSTART:19970317T133000Z REPEAT:4 DURATION:PT15M CATEGORIES:DISPLAY,AUDIO ATTACH:ftp://host.com/pub/sounds/bell-01.wav SUMMARY:Breakfast meeting with executive team at 8:30 AM END:VALARM 4.4.6 Timezone Component The "VTIMEZONE" calendar component is used to define a time zone. A time zone is unambiguously defined by the set of time measurement rules determined by the governing body for a given geographic area. These rules describe at a minimum the base offset from UTC for the time zone, often referred to as the Standard Time offset. Many locations adjust their Standard Time forward or backward by one hour, in order to accommodate seasonal changes in number of daylight hours, often referred to as Daylight Saving Time. Some locations adjust their time by a fraction of an hour. Standard Time is also known as Winter Time. Daylight Saving Time is also known as Advanced Time, Summer Time, or Legal Time in certain countries. The following table shows the changes in time zone rules for the eastern United States. Effective Transition Rule Date (Date/Time) Offset Abbreviation 1920-1920 last Sun in Mar, 02:00 _0400 EDT 1920-1920 last Sun in Oct, 02:00 _0500 EST 1921-1966 last Sun in Apr, 02:00 _0400 EDT 1921-1954 last Sun in Sep, 02:00 _0500 EST 1955-1966 last Sun in Oct, 02:00 _0500 EST 1967-* last Sun in Oct, 02:00 _0500 EST 1967-1973 last Sun in Apr, 02:00 _0400 EDT 1974-1974 Jan 6, 02:00 -0400 EDT 1975-1975 Feb 23, 02:00 -0400 EDT 1976-1986 last Sun in Apr, 02:00 _0400 EDT Dawson/Stenerson 33 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 1987-* first Sun in Apr, 02:00 _0400 EDT Interoperability between two calendaring and scheduling applications, especially for recurring events, to-dos or journal entries, is dependent on the ability to capture and convey date and time information in an unambiguous format. The specification of current time zone information is integral to this behavior. The "VTIMEZONE" calendar component is a grouping of component properties that define a time zone description. The time zone description specifies the effective Standard Time or Daylight Savings Time rules for a particular time zone. The "VTIMEZONE" calendar component cannot be nested within other calendar components. The "VTIMEZONE" calendar component MAY be specified multiple times. If the "VTIMEZONE" calendar component is missing, the recipient should assume all local times are relative to the recipient's time zone. The "VTIMEZONE" calendar component should be specified in the iCalendar object before any other calendar components. A "VTIMEZONE" calendar component is defined by the following notation: timezonec = "BEGIN" ":" [WSP] "VTIMEZONE" CRLF tzprop "END" ":" [WSP] "VTIMEZONE" CRLF tzprop = *comment [daylight] dtstart [rdate / rrule] [tzname] tzoffset The "VTIMEZONE" calendar component is important for correct interpretation of individual as well as recurring calendar components that span a time zone transition. For example, from EST to EDT. The exception to this are calendar components that are considered floating (i.e., occurs at a particular local time no matter what time zone you are in). If the iCalendar object contains a non-floating calendar component that has a recurring date pattern (i.e., includes the "RRULE" property) or a list of date and local time values (i.e., includes the "RDATE" property), one or more "VTIMEZONE" calendar 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 "VTIMEZONE" calendar component need be present. If a time zone transition is crossed, then other "VTIMEZONE" calendar components are needed. Further, if there are known changes to the rules for the time zone, even more "VTIMEZONE" calendar components are needed. Each "VTIMEZONE" calendar component consists of several properties: The "DAYLIGHT" property is a BOOLEAN value indicating Standard Time (FALSE) or Daylight Savings Time (TRUE). The default for DAYLIGHT is FALSE or Standard Time. Dawson/Stenerson 34 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 The "DTSTART" property in this usage is a fully specified DATE-TIME value, including the UTC offset, indicating the effective start date and time for the time zone information. For example, 19671029T020000- 0400 represents the time at which the transition to Standard Time took effect in 1967 for the eastern United States. The "TZOFFSET" property is a UTC-OFFSET value indicating the UTC offset for the time zone (Standard Time or Daylight Savings Time). The "TZNAME" property is the customary name for the time zone. The "RRULE" property indicates the recurrence rule for the transition to this time zone. For example, in the United States, the transition from Standard Time to Daylight Saving Time occurs on the first Sunday in April at 02:00. If a recurrence rule describing the transition is known to have an effective end date, the UNTIL recurrence rule parameter is used to specify that end date and time. If the recurrence rule for a particular observance (Daylight Saving Time) is changing, then the UNTIL of the first rule will be equal to the last valid instance (the last date-time) of this particular rule. See example below. Alternatively, the "RDATE" property can be used. The "RDATE" property is a property that indicates the individual dates and/or times that the transition takes effect. The values supplied for "RDATE" property for each "VTIMEZONE" calendar component MUST provide valid time zone information of all instances of the recurrence specified for the calendar component to which this time zone information is to be applied. The following are examples of the "VTIMEZONE" calendar component: This is a simple example showing time zone information for the Eastern United States using "RDATE" property. Note that this is only suitable for a recurring event that starts on or later than 1997, April 6, at 02:00:00 EST (i.e., the earliest effective transition date and time) and ends no later than 1998, April 7, 02:00:00 EST (i.e., latest valid date and time for EST in this scenario). For example, this can be used for a recurring event that ocurrs every Friday, 8am-9am, starting June 1, 1997, ending Dec 31, 1997. BEGIN:VTIMEZONE DAYLIGHT:FALSE RDATE:19971026T020000-0400 TZOFFSET:-0500 TZNAME:EST END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:TRUE RDATE:19970406T020000-0500 TZOFFSET:-0400 TZNAME:EDT END:VTIMEZONE Dawson/Stenerson 35 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 This is a simple example showing the current time zone rules for the Eastern United States using a RRULE recurrence pattern. Note that there is no effective end date to either of the Standard Time or Daylight Time rules. This information would be valid for a recurrening event starting today and continuing on into the known future. BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19671029T020000-0400 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSET:-0500 TZNAME:EST END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19870405T020000-0500 RRULE: FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSET:-0400 TZNAME:EDT END:VTIMEZONE This is an example showing a ficticious set of rules for the Eastern United States, where the Daylight Time rule has an effective end date (i.e., after that date, Daylight Time is no longer observed). BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19671029T020000-0400 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSET:-0500 TZNAME:EST END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19870405T020000-0500 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T020000-0500 TZOFFSET:-0400 TZNAME:EDT END:VTIMEZONE This is an example showing a fictitious set of rules for the Eastern United States, where the first Daylight Time rule has an effective end date. There is a second Daylight Time rule that picks up where the other left off. BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19671029T020000-0400 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSET:-0500 Dawson/Stenerson 36 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 TZNAME:EST END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19870405T020000-0500 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T020000-0500 TZOFFSET:-0400 TZNAME:EDT END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19990327T020000-0500 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZOFFSET:-0400 TZNAME:EDT END:VTIMEZONE 4.5 Calendar Properties The Calendar Properties are attributes that apply to the iCalendar object, as a whole. These properties do not appear within a calendar component. They should be specified after the "BEGIN:VCALENDAR" property and prior to any calendar component. 4.5.1 Calendar Scale This property is identified by the property name CALSCALE. This property defines the calendar scale used for the calendar information specified in the iCalendar object. This memo is based on the Gregorian calendar scale. The Gregorian calendar scale is assumed if this property is not specified in the iCalendar object. It is expected that other calendar scales will be defined in other specifications or by future versions of this memo. The property is defined by the following notation: calscale = "CALSCALE" ":" [WSP] calvalue CRLF calvalue = "GREGORIAN" / iana-token The following is an example of this property: CALSCALE:GREGORIAN The data type for this property is TEXT. 4.5.2 Method This property is identified by the property name METHOD. This property defines the iCalendar object method 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 "method" parameter Dawson/Stenerson 37 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 value. This property can only appear once within the iCalendar object. The property is defined by the following notation: method = "METHOD" ":" [WSP] profvalue CRLF profvalue = The following is an example of this property when the iCalendar object is used to request a meeting: METHOD: REQUEST The data type for this property is TEXT. 4.5.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. This property should not be used to alter the interpretation of an iCalendar object beyond the semantics specified in this memo. For example, it is not to be used to further the understanding of non- standard properties. The property is defined by the following notation: prodid = "PRODID" ":" [WSP] pidvalue CRLF pidvalue = text ;Any text that describes the product and version ;and that is generally assured of being unique. The following is an example of this property: PRODID:-//ABC Corporation//NONSGML My Product//EN The data type for this property is TEXT. 4.5.4 Source This property is identified by the property name SOURCE. This property is defined by the [MIME DIR] memo. In this memo, the property identifies the URI for the source of the iCalendar object. The URI is useful for accessing the iCalendar object using a calendar access protocol. The property is defined by the following notation: Dawson/Stenerson 38 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 source = "SOURCE" ":" [WSP] uri CRLF The following are examples of this property: SOURCE:http://xyz.corp.com/corp-cals/1997-events.or4 SOURCE:http://xyz.corp.com/calendars/~jdoe The data type for this property is URI. 4.5.5 Source Name This property is identified by the property name NAME. This property is defined by the [MIME DIR] memo. The property identifies the displayable, presentation name for the source of the iCalendar object. The source name is a useful text to associate in the user- interface of an application with the value in the SOURCE property. The property is defined by the following notation: name = "NAME" ":" [WSP] 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. 4.5.6 Version This property is identified by the property name VERSION. This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the MIME Calendaring and Scheduling Content Type specification supported by the implementation that created the iCalendar object. A value of "2.0" corresponds to this memo. This calendar property MUST appear within the iCalendar object but can only appear once. The property is defined by the following notation: version = "VERSION" ":" [WSP] vervalue CRLF vervalue = "2.0" ;This memo / maxver / (minver ";" [WSP] maxver) minver = ;Minimum iCalendar version used to create the iCalendar object maxver = ;Maximum iCalendar version used to create the iCalendar object The following is an example of this property: Dawson/Stenerson 39 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 VERSION:2.0 The data type for this property is TEXT. 4.6 Component Properties The following properties MAY appear within calendar components, as specified by each component property definition. 4.6.1 Attachment This property is identified by the property name ATTACH. The property provides the capability to associate an external object with a calendar component. For example, a document to be reviewed at a scheduled event or the description of the process steps for a to-do. The property MAY only be specified within "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. This property MAY be specified multiple times within an iCalendar object. The property is defined by the following notation: attach = ("ATTACH" ":" [WSP] uri CRLF) / ("ATTACH" ";" [WSP] "ENCODING" "=" "b" ";" [WSP] "VALUE" "=" "text" ":" [WSP] folded-b The following are examples of this property: ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com ATTACH:FTP://xyzCorp.com/pub/reports/r-960812.ps The default data type for this property is URI. The data type MAY also be reset to TEXT in order to include inline binary encoded content information. 4.6.2 Attendee This property is identified by the property name ATTENDEE. The property defines an attendee within a calendar component. The property MAY only be specified within the "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY" and "VALARM" calendar components. The property has the property parameters TYPE, for the type of attendee, ROLE, for the intended role of the attendee; STATUS, for the status of the attendee's participation; RSVP, for indicating whether the favor of a reply is requested; EXPECT, to indicate the expectation of the attendee's participation by the originator; MEMBER, to indicate the groups that the attendee belongs to; DELEGATED-TO, to indicate the people that the original request was delegated to; and DELEGATED-FROM, to indicated whom the request was delegated from. A recipient delegated a request MUST inherit the RSVP and EXPECT values from the attendee that delegated the request to them. Dawson/Stenerson 40 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 Multiple attendees MAY be specified by including multiple "ATTENDEE" properties within the MIME calendaring entity. The property data type default is CAL-ADDRESS. The property data type MAY also be set to URI. This provides a useful mechanism to allow more than just the address of the attendee to be referenced. If the value is a URI, then it MUST be able to be resolved to a calendar address. The property is defined by the following notation: attendee = "ATTENDEE" *(";" [WSP] parameter) *(";" [WSP] attparam) ":" [WSP] (cal-address / uri) CRLF ;Value MUST match default or explicit data type attparam = typeparm / roleparm / statusparm / rsvpparm / expectparm / memberparm / deletoparm / delefromparm typeparm = "TYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN") ; Otherwise not known ;Default value is INDIVIDUAL 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. / "IN-PROCESS" ;Indicates to-do is in the process of ; being completed. / "DELEGATED" ; Indicates event or to-do delegated ; to another ATTENDEE / "CANCELLED") ; Indicates event or to-do cancelled for ; ATTENDEE ;Default is NEEDS-ACTION rsvpparm = "RSVP" "=" ("TRUE" ; Indicates response requested / "FALSE") ; Indicates no response needed ;Default is FALSE Dawson/Stenerson 41 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 expectparm = "EXPECT" "=" ("FYI" ; Indicates request is for your info / "REQUIRE" ; Indicates presence is required / "REQUEST") ; Indicates presence is requested ;Default is FYI memberparm = "MEMBER" "=" cal-address *("," [WSP] cal-address) ; Indicates a group or mailing list deletoparm = "DELEGATED-TO" "=" cal-address *("," [WSP] cal-address) ; Indicates who the request is delegated to delefromparm = "DELEGATED-FROM" "=" cal-address *("," [WSP] cal-address) ;Indicates who the request is delegated from The following are examples of this property's use for a to-do: ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:MAILTO:jsmith@host1.com ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com": MAILTO:joecool@host2.com ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com": MAILTO:ildoit@host1.com The following is an example of this property used for specifying multiple attendees to an event: ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED: MAILTO:John Smith ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:MAILTO:Henry Cabot ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:MAILTOJane Doe The following is an example of this property with the value specified as an URI reference to a vCard that contains the information about the attendee: ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED;VALUE=URI: http://www.xyz.com/~myvcard.vcf The following is an example of this property with "delegatee" and "delegator" information for an event: ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO:John Smith ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM= "MAILTO:iamboss@host2.com":MAILTO:Henry Cabot ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO= "MAILTO:hcabot@host2.com:MAILTO:iamboss(The Big Cheese)@host2.com Dawson/Stenerson 42 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:MAILTO:Jane Doe The default data type for this property is CAL-ADDRESS. The data type MAY be reset to URI; in which case the value is a location or message that contains the information that is to be used to specify the attendee address. 4.6.3 Categories This property is identified by the property name CATEGORIES. This property defines the categories for a calendar component. The property MAY be specified within the "VEVENT", "VTODO" or "VJOURNAL" calendar component with an arbitrary text value. In the "VALARM" calendar component the property MUST be specified to declare 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" *(";" [WSP] parameter) ":" [WSP] catvalue CRLF catvalue = cat1value *["," [WSP] cat1value] / cat2value *["," [WSP] cat2value] cat1value = "ANNIVERSARY" / "APPOINTMENT" / "BUSINESS" / "EDUCATION" / "HOLIDAY" / "MEETING" / "MISCELLANEOUS" / "NON-WORKING HOURS" / "NOT IN OFFICE" / "PERSONAL" / "PHONE CALL" / "SICK DAY" / "SPECIAL OCCASION" / "TRAVEL" / "VACATION" / word ;Used only in "VEVENT", "VTODO" and "VJOURNAL" calendar components. cat2value = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" / iana-token / x-name ;Used only in "VALARM" calendar component. The following are examples of this property in a "VEVENT", "VTODO" or "VJOURNAL" calendar component: CATEGORIES:APPOINTMENT,EDUCATION CATEGORIES:MEETING The following are examples of this property in a "VALARM" calendar component: CATEGORIES:AUDIO,DISPLAY CATEGORIES:PROCEDURE The data type for this property is TEXT. Dawson/Stenerson 43 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.6.4 Classification This property is identified by the property name CLASS. This property defines the access classification for a calendar component. The property MAY only be specified in a "VEVENT", "VTODO" or "VJOURNAL" 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., calendar user authentication, authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications cannot be completely defined by this memo alone. Additionally, due to the "blind" nature of most exchange processes using this memo, these access classifications cannot serve as an enforcement statement for a system receiving an iCalendar object. Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar component. The [ICMS] provides a broader description of the security system within a calendar application. The property is defined by the following notation: class = "CLASS" ":" [WSP] classvalue CRLF classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token / x-name ;Default is PUBLIC The following is an example of this property: CLASS:PUBLIC The data type for this property is TEXT. 4.6.5 Comment This property is identified by the property name COMMENT. This property specifies non-processing information intended to provide a comment to the calendar user. The property MAY be specified in any of the calendar components. The property MAY be specified multiple times. The property is defined by the following notation: comment = "COMMENT" ":" [WSP] text CRLF The following is an example of this property: COMMENT:The meeting really needs to include both ourselves and the customer. We can't hold this meeting without them Dawson/Stenerson 44 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 As a matter of fact\, the venue for the meeting ought to be at their site. - - John The data type for this property is TEXT. 4.6.6 Contact This property is defined by the property name CONTACT. The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. The property MAY only be specified in the "VEVENT", "VTODO" and "VJOURNAL" calendar components. The property value consists of textual contact information. Alternately, the value type for the property can be reset such that the property references the URI to the contact information. The property is defined by the following notation: contact = "CONTACT" *(";" [WSP] parameter) ":" [WSP] text / uri CRLF The following is an example of this property referencing textual contact information: CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 The following is an example of this property referencing a LDAP URI to a directory entry containing the contact information: CONTACT;VALUE=URI:ldap://host.com:6666/o=3DABC%20Industries\, c=3DUS??(cn=3DBJim%20Dolittle) The following is an example of this property referencing a MIME body part containing the contact information, such as a vCard embedded in a [MIME-DIR] content-type: CONTACT;VALUE=URI: The default data type for this property is TEXT. The data type MAY be reset to URI in order to specify a reference to the contact information. 4.6.7 Date/Time Completed This property is identified by the property name COMPLETED. This property defines the date and time that a to-do was actually completed. The property MAY be specified once in a "VTODO" component. The date and time is an UTC value. The property is defined by the following notation: completed = "COMPLETED" ":" [WSP] date-time CRLF The following is an example of this property: Dawson/Stenerson 45 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 COMPLETED:19960401T235959Z The data type for this property is DATE-TIME. 4.6.8 Date/Time Created This property is identified by the property name CREATED. This property specifies the date and time that the calendar information was created by the Organizer. 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. The property is defined by the following notation: created = "CREATED" ":" [WSP] date-time CRLF The following is an example of this property: CREATED:19960329T133000Z The data type for this property is DATE-TIME. 4.6.9 Date/Time Due This property is identified by the property name DUE. This property defines the date and time that a to-do is expected to be completed. The time can either be in local time, local time with UTC offset or UTC time. The property MAY only be specified in a "VTODO" calendar component and only once. The value MUST be a date/time after the DTSTART value, if specified. The property is defined by the following notation: due = "DUE" ":" [WSP] date-time CRLF The following is an example of this property: DUE:19960401T235959Z The type for this property is DATE-TIME. 4.6.10 Date/Time End This property is identified by the property name DTEND. This property MAY be specified within the "VEVENT", "VFREEBUSY", and "VTIMEZONE" calendar components. Within the "VEVENT" calendar component, this property defines the end date and time for the event. The property is REQUIRED in "VEVENT" calendar components. The time can either be in local time, local time with UTC offset or UTC time. The local time is only to be used to specify date and time values that do not need to be fixed. A recipient MUST assume their own time zone for data and time values Dawson/Stenerson 46 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 that do not include time zone information. The value MUST be later in time than the value of the "DTSTART" property. Within the "VFREEBUSY" 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. The value MUST be later in time than the value of the "DTSTART" property. The property is defined by the following notation: dtend = "DTEND" ":" [WSP] date-time CRLF The following is an example of this property: DTEND:19960401T235959Z The data type for this property is DATE-TIME. 4.6.11 Date/Time Stamp This property is identified by the property name DTSTAMP. This property specifies an UTC date/time stamp. The property indicates the date/time that the iCalendar object instance was created. This property MUST be included in "VEVENT", "VTODO", "VJOURNAL" and "VFREEBUSY" calendar components to permit the recipient to know when the iCalendar object was created. This property is also useful to protocols such as [IMIP] that have inherent latency issues with the delivery of content. This property will assist in the proper sequencing of messages containing iCalendar objects. This property is different than the "CREATED" and "LAST-MODIFIED" properties. These two properties are used to specify when the calendar service information was created and last modified. This is different than when the iCalendar object representation of the calendar service information was created or last modified. The property is defined by the following notation: dtstamp = "DTSTAMP" ":" [WSP] date-time CRLF The value type for this property is DATE-TIME. The value MUST be a UTC date/time value. 4.6.12 Date/Time Start This property is identified by the property name DTSTART. This property MAY be specified within the "VEVENT", "VTODO", "VFREEBUSY", and "VTIMEZONE" calendar components. Within the "VEVENT" calendar component, this property defines the start date and time for the event. The property is REQUIRED in "VEVENT" calendar components. The time can either be in local time, Dawson/Stenerson 47 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 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 "VFREEBUSY" 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 "VTIMEZONE" calendar component, this property defines the effective start date and time for a time zone specification. This property is REQUIRED within "VTIMEZONE" calendar components. The time MUST be specified as a UTC time. The property is defined by the following notation: dtstart = "DTSTART" *(";" [WSP] parameter) ":" [WSP] (date-time / date) CRLF The following is an example of this property: DTSTART:19960401T235959-0600 The default data type for this property is DATE-TIME. The data type MAY be overridden to be DATE. 4.6.13 Daylight This property is identified by the property name DAYLIGHT. This property MAY only be specified in a "VTIMEZONE" calendar component. This property specifies whether Daylight Saving Time (i.e., value is TRUE) or Standard Time (i.e., value is FALSE) is in effect for the time zone. The default value is FALSE or Standard Time. The property is defined by the following notation: daylight = "DAYLIGHT" ":" [WSP] 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. 4.6.14 Description This property is identified by the property name DESCRIPTION. This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property. The property MAY be specified in the "VEVENT", "VTODO" and "VJOURNAL" calendar Dawson/Stenerson 48 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 components. The property MAY be specified multiple times only within a "VJOURNAL" calendar component. The property is defined by the following notation: description = "DESCRIPTION" *(";" [WSP] parameter) ":" [WSP] text CRLF The following is an example of the property with formatted line breaks in the property value: DESCRIPTION:Meeting to provide technical review for "Phoenix" design.\n Happy Face Conference Room. Phoenix design team MUST attend this meeting.\n RSVP to team leader. The following is an example of the property with folding of long lines: DESCRIPTION:Last draft of the new novel is to be completed for the editor's proof today. The data type for this property is TEXT. 4.6.15 Duration This property is identified by the property name DURATION. The property specifies a duration of time. The property MAY be specified in a "VEVENT" 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 "VTODO" calendar component in order to specify a duration for the to-do. The property MAY be specified in a "VFREEBUSY" calendar component in order to specify the amount of free time being requested. The property MAY be specified in an "VALARM" calendar component in order to specify the period between repeating alarms. The property is defined by the following notation: duration = "DURATION" ":" [WSP] 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. Dawson/Stenerson 49 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 4.6.16 Exception Date/Times This property is identified by the property name EXDATE. This property defines the list of date/time exceptions for a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The times can either be in local time, local time with UTC offset or UTC time. The exception dates, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the initial "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" property defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties MAY also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date-times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date and times which fall within the union of start date and times generated by any specified "EXRULE" and "EXDATE" properties. This implies that start date and times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. The "EXDATE" property MAY be used to exclude the value specified in "DTSTART". However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". The property is defined by the following notation: exdate = "EXDATE" *(";" [WSP] parameter) ":" [WSP] [date-time / date] *("," [WSP] date-time/date) CRLF ;Values MUST match the specified value type. The following is an example of this property: EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z The data type for this property is DATE-TIME. The data type MAY be reset to DATE. 4.6.17 Exception Rule This property is identified by the property name EXRULE. This property defines a rule or repeating pattern for an exception to a recurrence set. This property MAY only be specified in the "VEVENT", "VTODO" or "VJOURNAL" calendar components. The exception rule, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances Dawson/Stenerson 50 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 for a calendar component. The recurrence set is generated by considering the initial "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties MAY also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date-times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date and times which fall within the union of start date and times generated by any specified "EXRULE" and "EXDATE" properties. This implies that start date and times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. The "EXRULE" property MAY be used to exclude the value specified in "DTSTART". However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". The property is defined by the following notation: exrule = "EXRULE" ":" [WSP] recur CRLF The following are examples of this property. Except every other week, on Tuesday and Thursday for 4 occurrences: EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH Except daily for 10 occurrences: EXRULE:FREQ=DAILY;COUNT=10 Except yearly in June and July for 8 occurrences: EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7 The data type for this property is RECUR. 4.6.18 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 whether the information defines a free or busy time interval. Dawson/Stenerson 51 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 The default "TYPE" property parameter value is BUSY. The property MAY also include the "STATUS" property parameter to provide added information about the busy time. For example, if the busy time is associated with a time interval that would be unavailable for scheduling - - in any case - - or busy time that has been tentatively scheduled. The default "STATUS" property parameter value is BUSY. The property is defined by the following notation: freebusy = "FREEBUSY" *(";" [WSP] parameter) [";" [WSP] fbparmlist] ":" [WSP] fbvalue CRLF fbparmlist = fbparam *(";" [WSP] fbparam) fbparam = fbtype / fbstatus fbtype = "TYPE" "=" ("FREE" or "BUSY") ;Default is BUSY fbstatus = "STATUS" "=" "BUSY" ;Represents busy time interval. / "UNAVAILABLE" ;Represents busy, but unavailable ;interval for cheduling; such as ;out-of-office or non-working hours. / "TENTATIVE" ;Represents busy, but tentatively ;scheduled interval. ;Default is BUSY fbvalue = period *["," [WSP] period] ;Value MUST match default or explicit data type The following are some examples of this property: FREEBUSY;STATUS=UNAVAILABLE:19970308T160000Z/PT8H30M FREEBUSY;TYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H "FREEBUSY" properties within the "VFREEBUSY" calendar component should be sorted in ascending order, based on start time and then end time, with the earliest periods first. The "FREEBUSY" property MAY specify more than one value, separated by the COMMA character (ASCII decimal 44). In such cases, the "FREEBUSY" property values should all be of the same "STATUS" property parameter type (e.g., all values of a particular "STATUS" listed together in a single property). The data type for this property is PERIOD. 4.6.19 Geographic Position This property is identified by the property name GEO. This property specifies information related to the global position for a "VEVENT" or "VTODO" calendar component. The property value specifies latitude and longitude, in that order (i.e., "LAT LON" ordering). The Dawson/Stenerson 52 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 longitude represents the location east and west of the prime meridian as a positive or negative real number, respectively. The latitude represents the location north and south of the equator as a positive or negative real number, respectively. The longitude and latitude values MUST be specified as decimal degrees and should be specified to six decimal places. This will allow for granularity within a meter of the geographical position. The simple formula for converting degrees-minutes-seconds into decimal degrees is: decimal = degrees + minutes/60 + seconds/3600. The property is defined by the following notation: geo = "GEO" ":" [WSP] geovalue CRLF geovalue = float ";" [WSP] float ;Latitude and Longitude components The following is an example of this property: GEO:37.386013;-122.082932 The default data type for this property is FLOAT. 4.6.20 Last Modified This property is identified by the property name LAST-MODIFIED. The property specifies the date and time that the calendar information was last revised. This property MAY be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. The data and time MUST be a UTC value. The property is defined by the following notation: last-mod = "LAST-MODIFIED" ":" [WSP] date-time CRLF The following is are examples of this property: LAST-MODIFIED:19960817T133000Z The data type for this property is DATE-TIME. 4.6.21 Location This property is identified by the property name LOCATION. The property defines the intended location for the "VEVENT" or "VTODO" calendar component. The property MAY only be specified within a "VEVENT" or "VTODO" calendar component. The property is defined by the following notation: location = "LOCATION *(";" [WSP] parameter) ":" [WSP] locavalue CRLF Dawson/Stenerson 53 Expires MAY 1998 Internet Draft C&S Core Object Specification November 14, 1997 locavalue = text / uri ;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=URI:http://www.xyzcorp.com/~jsmith.vcf The default data type for this property is TEXT. The data type MAY be reset to URI. In the case of the data type being URI, the property value MAY reference a vCard object. This provides a useful mechanism to specify a location in terms of its electronic business card. 4.6.22 Percent Complete This property is identified by the property name PERCENT-COMPLETE. This property is used by an assignee or delegatee of a to-do to convey the percent completion of a to-do to the Organizer. The property MAY only be specified once and within a "VTODO" calendar component. The property value is an integer between zero and one hundred. A value of "0" indicates the to-do has not yet been started. A value of "100" indicates that the to-do has been completed. Integer values in between indicate the percent partially complete. When a to-do is assigned to multiple individuals, the property value indicates the percent complete for that portion of the to-do assigned to the assignee or delegatee. For example, if a to-do is assigned to both individuals "A" and "B". A reply from "A" with a percent complete of "70" indicates that "A" has completed 70% of the to-do assigned to them. A reply from "B" with a percent complete of "50" indicates "B" has completed 50% of the to-do assigned to them. The property is defined by the following notation: percent = "PERCENT-COMPLETE" ":" [WSP] integer CRLF The following is an example of this property to show 39% completion: PERCENT-COMPLETE:39 The data type for this property is INTEGER. 4.6.23 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 a "VEVENT" or "VTODO" 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)