CALSCH Working Group Surendra Reddy Internet Draft Oracle Corporation draft-reddy-scap-00.txt April 27, 1998 Expires October 27, 1998 Web based Simple Calendar Access Protocol - SCAP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the CALSCH working group at ietf-calendar@imc.org, which may be joined by sending a message with subject "subscribe" to ietf- calendar-request@imc.org. Abstract Distributed calendaring is gradually becoming more demanding than standalone calendaring and scheduling. The use of calendaring and scheduling has grown exponentially and enterprise and inter- enterprise business has become so dependent on group scheudling applications. But there is no Internet standard to provide interoperability among various calendaring applications. Consequently, user need to install different conduit programs to access these calendaring stores. This memo proposes a HTTP based simple calendaring access protocol which allows web, email and any HTTP compliant clients to access and manipulate calendar store. The motivation for this proposal is the expanded scope and diversity of the World Wide Web. The World Wide Web provides a simple and effective means for users to search, browse, retrieve, and publish Surendra Reddy [Page 1]
draft-ietf-calsch-scap-00.txt April 1998 information of their own available for others. Now that Web browsers and servers are ubiquitous on the Internet, it is worthwhile to use HTTP as transport protocol and XML to encode calendar objects. The power and extensibility of XML allows us to represent calendar data objects as well-formed XML documents. Simple Calendar Access Protocol(SCAP) allows exchanging calendaring information between scheduling systems using the Hypertext Transfer Protocol (HTTP). This allows users to schedule meetings with anyone else, no matter what scheduling software they use. This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of calender properties, creation and management of calendar objects, and namespace manipulation. Table of Contents i. Status of this Memo .......................................... 1 ii. Abstract .................................................... 1 1. Introduction ................................................ 4 2. Notational Conventions ...................................... 4 3. Calendar Object Model ....................................... 5 3.1 The Calendar Property Model ............................. 5 3.2 Property Values ......................................... 5 3.3 Property Names .......................................... 5 3.4 Calendar Names and User Names ........................... 5 4. HTTP Methods of Calendar Access ............................. 5 4.1 CSOP Method ............................................. 6 4.1.1 Create Calendar Store ............................. 6 4.1.2 Example: Create Calendar Store .................... 6 4.1.3 Example - Select Calendar Store ................... 7 4.1.4 Delete Calendar Store ............................. 8 4.1.5 Example: Delete Calendar Store .................... 8 4.1.6 Copy and Move Calendar Stores ..................... 9 4.1.7 Example: Rename Calendar Store .................... 9 4.1.8 List Calendar Store ............................... 10 4.1.9 Examples: List Calendar Store ..................... 10 4.1.10 Set Calendar View by Range ....................... 11 4.1.11 Example: Calendar View by Range .................. 11 4.2 MKCSOBJ ................................................. 12 4.2.1 Examples: ........................................ 12 4.3 CSPROP Method ........................................... 13 4.3.1 Example:Get Freebusy time ......................... 14 5. Calendar XML Element Definitions ............................ 15 5.1 Calendar Message ........................................ 15 5.2 vevent XML element ...................................... 16 Surendra Reddy [Page 2]
draft-ietf-calsch-scap-00.txt April 1998 5.2.1 Example: vevent ................................... 16 5.3 vtodo XML element ....................................... 17 5.3.1 Example: vtodo .................................... 18 5.4 vjournal XML element ................................... 18 5.4.1 Example: vjournal ................................ 19 5.5 vfreebusy XML element ................................... 19 5.5.1 Example: vfreebusy ................................ 20 5.5 vtimezone XML element ................................... 21 5.6.1 Example: vtimezone ................................ 22 5.6 valarm XML element ...................................... 23 5.6.1 Example: valarm ................................... 24 6. Calendar Properties ......................................... 25 6.1 attach Property ......................................... 25 6.2 categories Property ..................................... 26 6.3 class Property .......................................... 26 6.4 comment Property ........................................ 26 6.5 description Property .................................... 27 6.6 location Property ....................................... 27 6.7 percentcomplete Property ................................ 27 6.8 priority Property ....................................... 28 6.9 resources Property ...................................... 28 6.10 status Property ........................................ 28 6.11 summary Property ....................................... 29 6.12 completed property ..................................... 29 6.13 dtend Property ......................................... 29 6.14 due Property ........................................... 30 6.15 dtstart Property ....................................... 30 6.16 duration Property ...................................... 31 6.17 freebusy Property ...................................... 31 6.18 attendee Property ...................................... 32 6.19 contact Property ....................................... 33 6.20 organizer Property ..................................... 33 6.21 recurid Property ....................................... 34 6.22 relatedto Property ..................................... 35 6.23 url property ........................................... 35 6.24 uid Property ........................................... 35 6.25 exdate Property ........................................ 36 6.26 exrule Property ........................................ 36 6.27 rdate Property ......................................... 36 6.28 rrule Property ......................................... 37 6.29 trigger Property ....................................... 37 6.30 created Property ....................................... 38 6.31 dtstamp Property ....................................... 38 6.32 lastmodified Property .................................. 38 6.33 sequence Property ...................................... 39 6.34 requeststatus Property ................................. 39 7. Security Considerations ..................................... 40 8. Calendar Object Specification - XML DTD ..................... 40 Surendra Reddy [Page 3]
draft-ietf-calsch-scap-00.txt April 1998 8. References .................................................. 44 9. Author's Address ............................................ 45 1. Introduction This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote calendaring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: Properties: The ability to create, remove, and query information about Calendar resources, such as their freetime, todo etc. Namespace Operations: The ability to instruct the server to copy and move calendar objects. SCAP, encodes method parameter information either in an Extensible Markup Language (XML) [Bray, Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility, and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. As a rule of thumb, parameters are encoded in XML entity bodies when they have unbounded length, or when they may be shown to a human user and hence require encoding in an ISO 10646 character set. Otherwise, parameters are encoded within HTTP headers. In addition to encoding method parameters, XML is used in SCAP to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input. 2. Notational Conventions Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of [Fielding et al., 1997]. Since this augmented BNF uses the basic production rules provided in section 2.2 of [Fielding et al., 1997], these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Bradner, 1997]. Surendra Reddy [Page 4]
draft-ietf-calsch-scap-00.txt April 1998 3. Calendar Object Model 3.1. The Calendar Property Model Properties are pieces of data that describe the state of Calendar objects. Properties are data about data. [Refer iCalendar] The SCAP property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics. 3.2. Property Values The value of a property is, at minimum, well formed XML. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. 3.3. Property Names A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property. Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, so long as that property is "live" on the resources in question. The XML namespace mechanism, which is based on URIs, is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. 3.4. Calendar Names and User Names The name parameter can be the name of a Calendar and optionally a user name. 4. HTTP Methods of Calendar Access The following new HTTP methods use XML as a request and response format. All SCAP compliant clients and resources MUST use XML parsers that are complaint with [Bray, Paoli, Sperberg-McQueen, Surendra Reddy [Page 5]
draft-ietf-calsch-scap-00.txt April 1998 1998]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 Bad Request. If a client receives ill-formed XML in response then it SHOULD treat the server as malfunctioning. 4.1. CSOP Method The Calendar Store Operation(CSOP) method processes instructions specified in the request body. All SCAP compliant servers MUST support CSOP and MUST process instructions that are specified using csoperation XML element of SCAP schema. The request message body of a CSOP MUST contain at least one csoperation XML element. A client MUST submit csoperation XML element in the body of the request method decribing what action is being requested on the Request-URI. All SCAP complaiance servers MUST support returing a response of content type text/xml that contains a multistatus XML element that describes the results of the attempts to perform the various actions. If any requested operation is resulted in an error then the error result MUST be included in the response XML element. 4.1.1. Create Calendar Store Creates a new Calendar store with the given name. Calendar store names must begin with an alphabetic character and consist of alphanumeric characters. Calendar names are not case sensitive. It is illegal to create more than one Calendar store with the same name. "create" does not automatically select the Calendar store created. SCAP servers are NOT required to support hierarchical names. If a client attempts to create a Calendar Store with a hierarchical name on a server which does not support hierarchical names, the server MUST return an error response of to the "create" action request. If the Calendar name is suffixed with the hierarchy separator "/", this is a declaration that the client intends to create Calendar names under this name in the hierarchy. Server implementations that do not require this declaration MUST ignore it. 4.1.2. Example: Create Calendar Store >>Request CSOP HTTP/1.1 Surendra Reddy [Page 6]
draft-ietf-calsch-scap-00.txt April 1998 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> <C:csoperation> <create>Projects/</create> <create>Projects</create> </C:csoperation> >>Response HTTP/1.1 207 MULTI-STATUS Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <respone status="415" action="create" > HTTP/1.1 415 Unsupported </response> <response status="201"action="create" > HTTP/1.1 201 OK </response> </C:multistatus> The above example creates two Calendar stores for the default user. First operation failed as creating hierarchical Calendar store is not supported, hence server responded with a response code 415. 4.2. Example - Select Calendar Store >>Request CSOP HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> <C:csoperation> <select/> <select>Bob</select> <select><Sally</select> </C:csoperation> Surendra Reddy [Page 7]
draft-ietf-calsch-scap-00.txt April 1998 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <response status="201" store="Bob"> HTTP/1.1 424 Method Failure </response> <response status="201" store="Sally"> HTTP/1.1 424 Method Failure </response> </C:multistatus> This sequence uses multiple SELECT commands to open the current user's default Calendar store plus the default Calendar stores of Bob and Sally. 4.3. Delete Calendar Store Deletes the Calendar store with the given name. If this command is given from the Selected state, a currently selected Calendar cannot be deleted. 4.3.1. Example: Delete Calendar Store >>Request CSOP HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> <C:csoperation> <delete>Projects</delete> <delete>Purple/</delete> </C:csoperation> >>Response HTTP/1.1 207 MULTI-STATUS Content-Type: text/xml Content-Length: xxxx Surendra Reddy [Page 8]
draft-ietf-calsch-scap-00.txt April 1998 <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <respone status="201" action="delete" > HTTP/1.1 2O1 OK </response> <response status="415"action="delete" > HTTP/1.1 415 Unsupported </response> </C:multistatus> 4.4. Copy and Move Calendar Stores "copy" action transfer a given set of Objects to a different Calendar store. The "rename" action changes the name of a Calendar store. It is an error to attempt to rename from a Calendar name that does not exist or to a Calendar name that already exists and it MUST be responded to the client. If the hierarchy separator character appears in the new Calendar store name, the server SHOULD return an error response to the client. No actions MUST be performed on the Calendar Store. The Calendar store to "rename" or "copy" to MUST exist before the operation is initiated. 4.4.1. Example: Rename Calendar Store >>Request CSOP HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> <C:csoperation> <rename from ="Projects" to="ProjectScap"/> <rename from ="Purple" to="ProjectScap/PurpleScap/" /> </C:csoperation> >>Response Surendra Reddy [Page 9]
draft-ietf-calsch-scap-00.txt April 1998 HTTP/1.1 207 MULTI-STATUS Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <respone status="201" action="rename" > HTTP/1.1 2O1 OK </response> <response status="415"action="rename" > HTTP/1.1 415 Unsupported </response> </C:multistatus> 4.5. List Calendar Store The "list" action returns listresp XML for each Calendar store that matches the given reference and store name. The "*" character is a wildcard and can be used to matche any length string of valid Calendar Store name characters. The SCAP complaince servers must hide all Calendar stores that the current user does not have access to. These reference names should be interpreted in the following manner: allstores XML element - lists all top level Calendar stores accessible to the current user. allusers XML element - list all users accessible by the server curuser XML element - lists the currently authenticated user 4.5.1. Examples: List Calendar Store >>Request CSOP HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> <C:csoperation> Surendra Reddy [Page 10]
draft-ietf-calsch-scap-00.txt April 1998 <list><allstores/></list> </C:csoperation> >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <listresp type="STORES"> skreddy </listresp> <listresp type="STORES"> oracle </listresp> <listresp type="STORES"> nobody </listresp> </C:multistatus> 4.6. Set Calendar View by Range The "range" action sets a date/time range for the currently selected Calendars and returns a response with the number of items in the range. Either the start time(dtstart) or end time(dtend) can be replaced with the wildcard character "*" in which case lower or upper bound, respectively, is placed on the current date range. The start time given must be included in the range. The end time given must be excluded from the range. If any Object in the selected Calendar store contains a set of recurrence rules that resolve to dates within the specified date range, then that Object MUST appear once for each date resolved within the specified range. In other words, an Object may count for more than one Object in the response returned by the "range" action if it is a recurring Object. 4.6.1. Example: >>Request CSOP HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> Surendra Reddy [Page 11]
draft-ietf-calsch-scap-00.txt April 1998 <C:csoperation> <range> <dtstart>19971230T0900-0500</dtstart> <dtend>19971230T1700-0500</dtend> </C:csoperation> >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <rangeresp>9</rangeresp> </C:multistatus> 4.7. MKCSOBJ The MKCSOBJ method creates a new Calendar Object in the Calendar Store identified by the Request-URI. If the Calendar Store identified by the Request-URI does not exist, the server must return an error response with status codei 424. New Calendar Objects added to a Calendar store with the MKCSOBJ command MUST contain all required iCalendar properties specified in well formed XML request body. If a required property is missing the server MUST return a response and MUST not modify any of the specified Calendar stores. If a Calendar Object has been created on the Request-URI Calendar Store, the response SHOULD be 201(Created) and contain a response XML element which describes the status of the request. 4.7.1. Examples: >>Request MKCSOBJ Personal_Calendar HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as = "C"?> <C:vcalendar version="2.0"> <C:VEVENT> Surendra Reddy [Page 12]
draft-ietf-calsch-scap-00.txt April 1998 <C:DTSTART>19970606T140000-0800</DTSTART> <C:DTEND>19970606T150000-0800</DTEND> <C:DESCRIPTION>Meeting with Pete.</DTEND> <C:VEVENT> </C:VCALENDAR> >>Response HTTP/1.1 207 MULTI-STATUS Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:multistatus> <respone status="201" action="mkcsobj" > HTTP/1.1 2O1 OK </response> </C:multistatus> 4.8. CSPROP Method The CSPROP method returns information requested by the csprop XML element as a request body on the Calendar Store specified by the Request-URI. The CSPROP method currently supports the XML request bodies to retrive the various Calendar Store properties. getcsid The unique identifier of this Calendar store. getcomponents An iCalendar object gettimezone An iCalendar object containing a TIMEZONE Component getfreebusy Get freebusy time for the specified "resource" fetch Fecthes the specifies properites from the Calendar Store store Update the Calendar Objects specfied by the vcalendar XML request body in the calendar store specified by the Request-URI. search Searches the Calendar store for given properties. The "getcomponents" XML element can be used by a client to determine which Calendar Components that can be stored within a Calendar Store, along with the names and types of the properties of those Calendar Components. The server MUST return an iCalendar object which contains a "model" of all the Components the Calendar Store supports. The "model" Components MUST contain all of the properties that the Component can store. The Properties should specify a VALUE property parameter that identifies the data-type of the property. The property value MUST be an null string. The server does not have to return a TIMEZONE Component to Surendra Reddy [Page 13]
draft-ietf-calsch-scap-00.txt April 1998 indicate that this Component is supported. The server MUST return an ALARM Component if this Component is supported. The "getfreebusy" action searches the currently selected Calendars, bounded by a start and end time, and returns a list of intervals during which an event of the given length of time can be scheduled. The "fetch" action fetches all the specified calendar Objects from the Calendar store specified by the Request-URI. Note that items returned by "fetch" action should always be returned in ascending chronological order, even when multiple Calendar stores are selected. The "store" action updates the iCalendar data associated with this Calendar Object. The request body must contain well formed vcalendar XML elements and Calendar Store must be specified by Request-URI. If there is more than one Calendar store selected in the given selected object, then the "store" action will add the new Object to all of the Calendar stores. New Calendar Objects added to a Calendar store must contain all required iCalendar properties. Updates to existing Calendar Objects need only contain the actual data to be updated. Duplicate attributes names are not allowed, whenever a value is given for a attribute name that already exists, the new value replaces the old value. The "search" action searches the Calendar store for Objects that match the given searching criteria. Searching criteria consist of one or more search keys. The untagged SEARCH response from the server contains a listing of Object numbers corresponding to those Objects that match the searching criteria. When multiple keys are specified, the result is the intersection (AND function) of all the messages that match those keys. A search key can also be a parenthesized list of one or more search keys (e.g. for use with the OR and NO keys). 4.8.0.1. Example:Get Freebusy time >>Request CSPROP / HTTP/1.1 HOST: www.foo.com Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> Surendra Reddy [Page 14]
draft-ietf-calsch-scap-00.txt April 1998 <?xml:namespace name="SCAP:" as = "C"?> <getfreebusy> <csname>Ann</csname> <csname>Bob</csname> <dtstart>19970930T0900-0700</dtstart> <dtend>19970930T1700-0700</dtend> </freebusyreq> >>Response HTTP/1.1 200 OK Content-Type: text/xml Content-Length: xxxx <?xml version="1.0"?> <?xml:namespace name="SCAP:" as ="C"?> <C:vcalendar version="2.0"> <vfreebusy> <attendee>Ann</attendee> <dtstart>19970930T0900-0700</dtstart> <dtend>19970930T1700-0700<dtend> <freebusy value="PERIOD-START"> 19970930T1000-0700/PT1H </freebusy> <freebusy value="period-start"> 19970930T1200-0700/PT1H </freebusy> </vfreebusy> </vcalendar> In the example above, only two busy periods were found for the given time range: Ann is busy from 10 to 11 on 19970903 and also busy from 12 to 1 o'clock on the same day. 5. Calendar XML Element Definitions 5.1. Calendar Message Calendar messages are [XML] documents which are sent between SCAP client and server. the XML definition of a Calendar message is as follows: <!ELEMENT vcalendar ( vevent | vtodo | vjournal | vfreebusy | vtimezone )+)> <!ATTLIST vcalendar version PCDATA #REQUIRED prodid PCDATA #REQUIRED > Surendra Reddy [Page 15]
draft-ietf-calsch-scap-00.txt April 1998 5.2. vevent XML element Name: vevent Purpose: Provide a grouping of component properties that describe an event. Description: A vevent XML element is a grouping of component properties and an OPTIONAL "valarm" XML element that represent a scheduled amount of time on a calendar. <!ELEMENT vevent (attach*, attendee*, categories*, class?, comment*, contact*, created?, description?, (dtend|duration)?, dtstart, exdate*, exrule*, lastmodified?, location?, organizer?, priority?, rstatus? related*, resources*, rdate*, rrule*, dtstamp, sequence?, status? summary, transp?, uid, url?, recurid?)> The "vevent" calendar component MUST include the "dtstamp", "dtstart", "summary" And "uid" properties.`In addition, it MUST include the "sequence" property, if It's value is greater than zero. 5.2.1. Example 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: <vevent> <uid>19970901T130000Z-123401@host.com</uid> <dtstamp>19970901T1300Z</dtstamp> <dtstart>19970903T163000Z</dtstart> <dtend>19970903T190000Z</dtend> <summary>Annual Employee Review</summary. <class>PRIVATE</class> <categories><BUSINESS></categories> <categories>HUMAN RESOURCES</categories> </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: <vevent> <uid>19970901T130000Z-123402@host.com</uid> <dtstamp>19970901T1300Z</dtstamp> <dtstart>19970401T163000Z</dtstart> <dtend>19970402T010000Z</dtend> <summary>Laurel is in sensitivity awareness class.</summary> <class>PUBLIC</class> Surendra Reddy [Page 16]
draft-ietf-calsch-scap-00.txt April 1998 <categories>BUSINESS</categories> <categories>HUMAN RESOURCES</categories> <transp>transpARENT</TANSP> </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: <vevent> <uid>19970901T130000Z-123403@host.com</uid> <dtstamp>19970901T1300Z</dtstand> <dtstart>19971102</dtstart> <summary>Our Blissful Anniversary</summary> <class>CONFIDENTIAL</class> <categories>ANNIVERSARY</categories> <categories>PERSONAL</categories> <categories>SPECIAL OCCASION</categories> <rrule FREQ=YEARLY/> </vevent> 5.3. vtodo XML element Name: vtodo Purpose: Provide a grouping of calendar properties that describe a to-do. Description: A "vtodo" calendar component is a grouping of component properties and an OPTIONAL "valarm" calendar component that represent an action-item or assignment. <!ELEMENT vtodo (attach*, attendee*, categories*, class?, comment*, contact*, completed?, created?, description?, (dtend|duration)?, dtstart?, exdate*, exrule*, lastmodified?, location?, organizer?, percent?, priority, rstatus? related*, resources*, rdate*, rrule*, dtstamp, sequence?, status? summary, transp?, uid, url?, recurid?)> The "vtodo" calendar component MUST include the "dtstamp", "priority", "summary" and "uid" properties. In addition, it MUST include the "sequence" property, if it's value is greater than zero. A "vtodo" calendar component without the "dtstart" and "due" (or "duration") properties specifies a to-do that is associated with each successive calendar dates, until it is completed. Surendra Reddy [Page 17]
draft-ietf-calsch-scap-00.txt April 1998 5.3.1. Example: vtodo The following is an example of a "vtodo" calendar component: <vtodo> <uid>19970901T130000Z-123404@host.com</uid> <dtstamp>19970901T1300Z</dtstamp> <dtstart>19970415T133000Z</dtstart> <due>19970416T045959Z</due> <summary>1996 Income Tax Preparation</summary> <class>CONFIDENTIAL</class> <categories>FAMILY</categories> <categories>FINANCE</categories> <priority>1</priority> <status>NEEDS-ACTION</status. </vtodo> 5.4. vjournal XML element Name: vjournal Purpose: Provide a grouping of component properties that describe a journal entry. Description: 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 "vjournal" 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. <!ELEMENT vjournal (attach*, attendee*, categories*, class?, comment*, contact*, created?, description, dtstart, dtstamp, exdate*, exrule*, lastmodified?, organizer?, rstatus? related*, rdate*, rrule*, sequence?, summary, uid, url?, recurid?)> The "vjournal" calendar component MUST include the "dtstamp", "dtstart", "description", "summary" an "uid" properties. In addition, it MUST include the "sequence" property, if it's value is greater Surendra Reddy [Page 18]
draft-ietf-calsch-scap-00.txt April 1998 than zero. 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. 5.4.1. Example: The following is an example of the "vjournal" calendar component: <vjournal> <uid>19970901T130000Z-123405@host.com</uid> <dtstamp>19970901T1300Z</dtstamp> <dtstart VALUE=DATE>19970317</dtstart> <summary>Staff meeting minutes</summary> <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). </description> <vjournal> 5.5. vfreebusy XML element Name: vfreebusy Purpose: Provide a grouping of component properties that describe either a request for free/busy time, describe a response to a request for free/busy time or describe a published set of busy time. Description: A "vfreebusy" calendar component is a grouping of component properties that represents either a request for, a reply to a request for free or busy time information or a published set 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. 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. Surendra Reddy [Page 19]
draft-ietf-calsch-scap-00.txt April 1998 <!ELEMENT vfreebusy( freebusyreq|freebusyresp|busytime )> <!ELEMENT freebusyreq ( attendee, dtstamp, dtstart, dtend, uid, sequence?)> <!ELEMENT freebusyresp( attendee, dtstamp, freebusy, uid )> <!ELEMENT busytime (attendee, dtstamp, dtstart, dtend, freebusy)> The "vfreebusy" calendar component MUST include one of the "freebusyreq", "freebusyresp" or "busytime" calendar components. The "freebusyreq" component MUST include the "attendee", "dtstamp", "dtstart", "dtend", and "uid" properties. In addition, it MUST include the "sequence" property, if it's value is greater than zero. The "freebusyresp" component MUST include the "attendee", "dtstamp", "freebusy", and "uid" properties. In addition, it MUST include the "sequence" property, it's value is greater than zero. The "busytime" component MUST include the "attendee", "dtstamp", "dtstart", dtend", and "freebusy" properties. 5.5.1. Example: The following is an example of a "vfreebusy" calendar component used to request free or busy time information: <vfreebusy> <freebusyreq> <organizer MAILTO>jane_doe@host1.com</ORAGANIZER> <attendee MAILTO:john_public@host2.com</attendee> <dtstart>19971015T050000Z</dtstart> <dtend>19971016T050000Z<dtend> <dtstamp>19970901T083000Z<dtstamp> <sequence>0</sequence> <uid>19970901T0830000-uid1@host1.com</uid> </freebusyreq> <vfreebusy> The following is an example of a "vfreebusy" calendar component used to reply to the request with busy time information: <vfreebusy> <freebusyresp> <attendee MAILTO>john_public@host2.com</attendee> <dtstamp>19970901T100000Z</dtstamp> <sequence>0</sequence> <uid>19970901T0830000-uid1@host1.com</uid> <freebusy VALUE=PERIOD>19971015T050000Z/PT8H30M, 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M</freebusy> <URL>http://host2.com/pub/busy/jpublic-01.vcs</URL> </freebusyresp> <comment> Surendra Reddy [Page 20]
draft-ietf-calsch-scap-00.txt April 1998 This iCalendar file contains busy time information for the next three months.</comment> <vfreebusy> The following is an example of a "vfreebusy" calendar component used to published busy time information. <vfreebusy> <busytime> <attendee:jsmith@host.com <dtstart:19980313T141711Z <dtend:19980410T141711Z <freebusy>19980314T233000Z/19980315T003000Z</freebusy> <freebusy>19980316T153000Z/19980316T163000Z</freebusy> <freebusy>19980318T030000Z/19980318T040000Z</freebusy> <URL>http://www.host.com/calendar/busytime/jsmith.ifb</URL> </busytime> <vfreebusy> 5.6. vtimezone XML element Name: vtimezone Purpose: Provide a grouping of component properties that defines a time zone. Description: 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. If present, the "vtimezone" calendar component defines the set of Standard Time and Daylight Saving Time observances (or rules) for a particular time zone for a given interval of time. The "vtimezone" calendar component cannot be nested within other calendar components. Multiple "vtimezone" calendar components MAY exist in an iCalendar object. In this situation, each "vtimezone" MUST represent a unique time zone definition. This is necessary for some classes of events, such as airline flights, that start in one time zone and end in another. <!ELEMENT vtimezone ( tzid, lastmodified?, tzurl?, (standard | daylight)) > <!ELEMENT standard ( comment*, dtstart, (rdate |rrule)?. tzname*, tzoffsetto, tzoffsetfrom)> <!ELEMENT daylight ( comment*, dtstart, (rdate | rrule )?, tzname*, tzoffsetto, tzoffsetfrom)> Surendra Reddy [Page 21]
draft-ietf-calsch-scap-00.txt April 1998 The properties in a "vtimezone" calendar componets are: The mandatory "tzid" property is a text value that uniquely idenifies the "vtimezone" calendar component within the scope of an iCalendar object. The optional "lastmodified" property is a UTC value that specifies the date and time that this timezone definition was updated. The optional "tzurl" property is a url value that points to a published "vtimezone" definiton. 5.6.1. Example: 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 April 6, 1997 at 02:00:00 EST (i.e., the earliest effective transition date and time) and ends no later than April 7, 1998 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 occurs every Friday, 8am-9am, starting June 1, 1997, ending December 31, 1997. <vtimezone> <tzid>America-New_York</tzid> <lastmodified>19870101T000000Z<lastmodified> <standard> <dtstart>19971026T020000</dtstart> <rdate>19971026T020000</rdate> <tzoffsetfrom>-0400</tzoffsetfrom> <TZOFFSETTO>-0500</TZOFFSETTO> <TZNAME>EST</TZNAME> </standard <daylight <dtstart>19971026T020000</dtstart> <rdate>19970406T020000</rdate> <tzoffsetfrom>-0500<tzoffsetfrom> <tzoffsetto>-0400</tzoffsetto> <tzname>EDT</tzname> </daylight> END:vtimezone This is a simple example showing the current time zone rules for the Eastern United States using a rrule recurrence pattern. Note that there is no effective end date to either of the Standard Time or Daylight Time rules. This information would be valid for a recurring event starting today and continuing on into the known future. <vtimezone> <tzid>America-New_York<tzid> Surendra Reddy [Page 22]
draft-ietf-calsch-scap-00.txt April 1998 <lastmodified>19870101T000000Z</lastmodified> <tzurl>http://zones.stds_r_us.net/tz/America-New_York</tzurl> <standard> <dtstart>19671029T020000</dtstart> <rrule:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10/> <tzoffsetfrom>-0400</tzoffsetfrom> <tzoffsetto>-0500</tzoffsetto> <tzname>EST</tzname> </standard> <daylight> <dtstart>19870405T020000 </dtstart> <rrule FREQ=YEARLY;BYDAY=1SU;BYMONTH=4/> <tzoffsetfrom>-0500</tzoffsetfrom> <tzoffsetto>-0400</tzoffsetto> <tzname>EDT</tzname> </daylight> </vtimezone> This is an example showing a fictitious 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). <vtimezone> <tzid>America-New_York</tzid> <lastmodified>19870101T000000Z</last-modified> <standard> <dtstart>19671029T020000 <rrule FREQ=YEARLY BYDAY=-1SU BYMONTH=10/> <tzoffsetfrom>-0400<tzoffsetfrom> <TZOFFSETTO>-0500</tzoffsetto> <tzname>EST</tzname> <standard> <daylight> <dtstart>19870405T020000</dtstart> <rrule FREQ=YEARLY BYDAY=1SU BYMONTH=1 UNTIL=19980404T070000/> <tzoffsetfrom>-0500</tzoffsetfrom> <tzoffsetto>-0400</tzoffsetto> <tzname>EDT</tzname> </daylight> </vtimezone> 5.7. valarm XML element Name: valarm Purpose: Provide a grouping of component properties that define an alarm. Surendra Reddy [Page 23]
draft-ietf-calsch-scap-00.txt April 1998 Description: A "valarm" calendar component is a grouping of component properties that is a reminder or alarm for an event or a to-do. For example, it may be used to define a reminder for a pending event or an overdue to-do. The "valarm" calendar component MUST include the "alarmtype" and "trigger" properties. In addition, an AUDIO type of alarm MUST include the "attach" property to point to a digital sound resource to be played. The DISPLAY type of alarm MUST include the "description" property. The EMAIL type of alarm MUST include the "attendee", "description" and "summary" properties. The PROCEDURE type of alarm MUST include the "attach" property to point to a procedure resource to be invoked. The "valarm" calendar component MUST only appear within either a "vevent" or "vtodo" calendar component. The "valarm" calendar components cannot be nested. Multiple "valarm" calendar components MAY be specified. <!ELEMENT valarm ( alarmtype, (trigger, (duration, repeat)?, attach) | (description, trigger, (duration, repeat)?) | (attendee*, attach*, description, trigger, (duration, repeat)?, summary) | (attach, description?, trigger, (duration, repeat)?))> 5.7.1. Example: The following example is for a "valarm" calendar component that specifies an audio alarm that will sound at a precise time and repeat 4 more times at 15 minute intervals: <valarm> <alarmtype>AUDIO</alarmtype> <trigger value=DATE-TIME>19970317T133000Z</trigger> <repeat>4</repeat> <duration>PT15M</duration> <attach>ftp://host.com/pub/sounds/bell-01.wav</attach> <valarm> The following example is for a "valarm" calendar component that specifies a display alarm that will trigger 15 minutes before the scheduled start of the event or the due date/time of the to-do it is associated with and will repeat 2 more times at 15 minute intervals: <valarm> <alarmtype>DISPLAY</alarmtype> <description>Breakfast meeting with executive team at 8:30 AM EST.</description> <trigger>PT30M</trigger> <repeat>2</repeat> Surendra Reddy [Page 24]
draft-ietf-calsch-scap-00.txt April 1998 <duration>PT15M</duration> <valarm> The following example is for a "valarm" calendar component that specifies an email alarm that will trigger 2 days before the scheduled due date/time of a to-do it is associated with. It does not repeat. The email has a subject, body and attachment link. <valarm> <alarmtype>EMAIL</alarmtype> <attendee>mailto:john_doe@host.com</attendee> <trigger>P2D</trigger> <summary> *** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** </summary> <description> A draft agenda needs to be sent out to the attendees to the weekly managers meeting (MGR-LIST). Attached is a pointer the document template for the agenda file. </description> <attach>http://host.com/templates/agenda.doc</attach> </valarm> The following example is for a "valarm" calendar component that specifies a procedural alarm that will trigger at a precise date/time and will repeat 23 more times at one hour intervals. The alarm will invoke a procedure file. <valarm> <alarmtype>PROCEDURE</alarmtype> <trigger VALUE=DATE-TIME> 19980101T050000Z </trigger> <repeat>23</repeat> <duration>PT1H</duration> <attach>ftp://host.com/novo-procs/felizano.exe</attach> </valarm> 6. Calendar Properties Property: A property is the definition of an individual attribute describing a calendar property or a calendar component. Property names, attribute names and attribute values are case insensitive. 6.1. attach Property Name: attach Purpose: The property provides the capability to associate a document object with a calendar component. Value: URI ; The default value type for this property is URI. The value type MAY also be reset to BINARY in order to include inline Surendra Reddy [Page 25]
draft-ietf-calsch-scap-00.txt April 1998 binary encoded content information. Description: 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. <!ELEMENT attach (#PCDATA) > <!ATTLIST attach encoding NMTOKEN #REQUIRED value CDATA #REQUIRED > 6.2. categories Property Name: categories Purpose: This property defines the categories for a calendar component. Description: This property is used to specify categories or subtypes of the calendar component. The categories are useful in searching for a calendar component of a particular type and category. Within the "vevent", "vtodo" or "vjournal" calendar components, more than one category MAY be specified as a list of categories separated by the COMMA character (ASCII decimal 44). <!ELEMENT categories (#PCDATA) > <!ATTLIST categories language NMTOKEN #REQUIRED > 6.3. class Property Name: class Purpose: This property defines the access classification for a calendar component. Description: 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. <!ELEMENT class (#PCDATA)> 6.4. comment Property Name: comment Purpose: This property specifies non-processing information intended to provide a comment to the calendar user. Surendra Reddy [Page 26]
draft-ietf-calsch-scap-00.txt April 1998 Description: The property MAY be specified multiple times. <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> 6.5. description Property Name: description Purpose: This property provides a more complete description of the calendar component, than that provided by the "summary" property. Description: This property is used to capture lengthy textual decriptions associated with the activity. <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> 6.6. location Property Name: location Purpose: The property defines the intended venue for the activity defined by a calendar component. Description: Specific venues such as conference or meeting rooms may be explicitly specified using this property. An alternate representation may be specified that is a URI that points to directory information with more structured specification of the location. <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> 6.7. percentcomplete Property Name: percentcomplete Purpose: 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. Surendra Reddy [Page 27]
draft-ietf-calsch-scap-00.txt April 1998 Description: The property value is a postive integer between zero and one hundred. A valu e 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. 6.8. priority Property Name: priority Purpose: The property defines the relative priority for a calendar component. Description: The priority is specified as an integer in the range zero to nine. A value of zero (ASCII decimal 48) specifies an undefined priority. A value of one (ASCII decimal 49) is the highest priority. A value of two (ASCII decimal 50) is the second highest priority. Subsequent numbers specify a decreasing ordinal priority. A value of nine (ASCII decimal 58) is the lowest priority. Within a "vevent" calendar component, this property specifies a priority for the event. This property may be useful when more than one event is scheduled for a given time period. Within a "vtodo" calendar component, this property specified a priority for the to-do. This property is useful in prioritizing multiple action items for a given time period. 6.9. resources Property Name: resources Purpose: This property defines the equipment or resources anticipated for an activity specified by a calendar entity.. Description: The property value is an arbitrary text. More than one resource MAY be specified as a list of resources separated by the COMMA character (ASCII decimal 44). <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED > 6.10. status Property Name: status Surendra Reddy [Page 28]
draft-ietf-calsch-scap-00.txt April 1998 Purpose: This property defines the overall status or confirmation for the calendar component. Description: In a group scheduled calendar component, the property is used by the "Organizer" to provide a confirmation of the event to the "Attendees". For example in a "vevent" calendar component, the "Organizer" can indicate that a meeting is tentative, confirmed or cancelled. In a "vtodo" calendar component, the "Organizer" can indicate that an action item needs action, is completed, is in process or being worked on, or has been cancelled. In a "vjournal" calendar component, the "Organizer" can indicate that a journal entry is draft, final or has been cancelled or removed. 6.11. summary Property Name: summary Purpose: This property defines a short summary or subject for the calendar component. Description: This property is used to capture a short, one line summary about the activity or journal entry. <!ELEMENT summary(#PCDATA)> <!ATTLIST summary language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> 6.12. completed property Property Name: completed Purpose: This property defines the date and time that a to-do was actually completed. Value : DATE-TIME Description: The date and time must be in a UTC format. 6.13. dtend Property Name: dtend Purpose: This property specifies the date and time that a calendar component ends. Surendra Reddy [Page 29]
draft-ietf-calsch-scap-00.txt April 1998 Value: DATE-TIME; The default value type is DATE-TIME. The value type MAY BE reset to a DATE value type. Description: Within the "vevent" calendar component, this property defines the date and time by which the event ends. 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 as in the UTC time format. The value MUST be later in time than the value of the "dtstart" property. <!ELEMENT dtend(#PCDATA)> <!ATTLIST dtend value NMTOKEN #REQUIRED tzid NMTOKEN #REQUIRED> 6.14. due Property Name: due Purpose: This property defines the date and time that a to-do is expected to be completed. Value: DATE-TIME ; The default value type is DATE-TIME. The value type MAY BE reset to a DATE value type. Description: The value MUST be a date/time equal to or after the dtstart value, if specified. <!ELEMENT due(#PCDATA)> <!ATTLIST due value NMTOKEN #REQUIRED tzid NMTOKEN #REQUIRED> 6.15. dtstart Property Name: dtstart Purpose: This property specifies when the calendar component begins. Value: DATE-TIME; The default value type is DATE-TIME. The DATE-TYPE value will be one of the forms defined for the DATE-TIME value type. The value type MAY BE reset to a DATE value type. Description: Within the "vevent" calendar component, this property Surendra Reddy [Page 30]
draft-ietf-calsch-scap-00.txt April 1998 defines the start date and time for the event. The property is REQUIRED in "vevent" calendar components. 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 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 in the UTC time format. <!ELEMENT dtstart(#PCDATA)> <!ATTLIST dtstart value NMTOKEN #REQUIRED tzid NMTOKEN #REQUIRED> 6.16. duration Property Name: duration Purpose: The property specifies a duration of time . Value : duration Description: In a "vevent" calendar component the property may be used to specify a duration of the event, instead of an explicit end date/time. In a "vtodo" calendar component the property may be used to specify a duration for the to-do, instead of an explicit due date/time. In a "VFREEBUSY" calendar component the property may be used to specify the interval of free time being requested. In a "VALARM" calendar component the property may be used to specify the delay period prior to repeating an alarm. 6.17. freebusy Property Name: freebusy Purpose: The property defines one or more free or busy time intervals. Value : PERIOD; The data and time value MUST be in a UTC time format. Surendra Reddy [Page 31]
draft-ietf-calsch-scap-00.txt April 1998 Description: 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 MUST be a UTC time format. The "FREEBUSY" property MAY include the "TYPE" property parameter to specify whether the information defines a FREE or BUSY time interval. The default "TYPE" property parameter value is BUSY. If the "TYPE" property parameter is set to "BUSY", then the property MAY also include the "BSTAT" 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 the parameter MAY BE set to UNAVAILABLE or if the busy time that has been tentatively scheduled the parameter MAY BE set to TENTATIVE. The default "BSTAT" property parameter value is BUSY, providing no additional busy status information. "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 "TYPE" and "BSTAT" property parameter type (e.g., all values of a particular "TYPE" and "BSTAT" listed together in a single property). <!ELEMENT freebusy(#PCDATA)> <!ATTLIST freebusy type (busy|free) bstat (busy|unavialable|trntative) 6.18. attendee Property Name: attendee Purpose: The property defines an attendee within a calendar component. Value: CAL-ADDRESS ; See Calendar Object Specification for more info. Conformance: This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. This property MUST be specified in an iCalendar object that specifies the publication of a calendar user's busy time. This property is not specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but Surendra Reddy [Page 32]
draft-ietf-calsch-scap-00.txt April 1998 are entities only on a single user's calendar. Description: The property is specified within the "vevent", "vtodo", "vjournal calendar components to specify participants, non- participants and the chair of a group scheduled calendar entity. The property is specified within the "VFREEBUSY" calendar component to specify the calendar user associated with the free or busy time. The property is specified within an "EMAIL" category of the "VALARM" calendar component to specify an email address that is to receive the email type of iCalendar alarm. 6.19. contact Property Name: contact Purpose: The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. Description: The property value consists of textual contact information. An alternative representation for the property value MAY also be specified that refers to a URI pointing to an alternate form, such as a vCard, for the contact information. <!ELEMENT contact(#PCDATA)> <!ATTLIST contact language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> 6.20. organizer Property Name: organizer Purpose: The property defines the organizer for a calendar component. Value: CAL-ADDRESS Description: The property is specified within the "vevent", "vtodo", "vjournal calendar components to specify the organizer of a group scheduled calendar entity. The property is specified within the "VFREEBUSY" calendar component to specify the calendar user requesting the free or busy time. <!ELEMENT organizer(#PCDATA)> <!ATTLIST organizer cn NMTOKEN #REQUIRED Surendra Reddy [Page 33]
draft-ietf-calsch-scap-00.txt April 1998 sentby NMTOKEN #REQUIRED dir NMTOKEN #REQUIRED> The property has the property parameters CN, for specifying the common or display name associated with the "Organizer", DIR, for specifying a pointer to the directory information associated with the "Organizer", SENT-BY, for specifying another calendar user that is acting on behalf of the "Organizer". No other parameters MAY be specified on this property. 6.21. recurid Property Name: recurid Purpose: This property is used in conjunction with the "uid" and "sequence" property to identify a specific instance of a recurring "vevent", "vtodo" or "vjournal" calendar component. The property value is the effective value of the "dtstart" property of the recurrence instance. Value Type: DATE-TIME; The default value type for this property is DATE-TIME. The time format MAY BE any of the valid forms defined for a DATE-TIME value type. See DATE-TIME value type definition for specific interpretations of the various forms. The value type MAY be reset to DATE. Description: The full range of calendar components specified by a recurrence set is referenced by referring to just the "uid" property value corresponding to the calendar component. The "recurrence-id" property allows the reference to an individual instance within the recurrence set. If the value of the "dtstart" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. The date/time value is set to the time when the original recurrence instance would occur - - meaning that if the intent is to change a Friday meeting to Thursday, the date/time is still set to the original Friday meeting. The "recurrence-id" property is used in conjunction with the "uid" and "SEQUENCE" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "uid" and "SEQUENCE" property values, the "recurrence-id" value for a recurrence instance is fixed. <!ELEMENT recurid(#PCDATA)> Surendra Reddy [Page 34]
draft-ietf-calsch-scap-00.txt April 1998 <!ATTLIST recurid value (date-time | date | period ) range ( thisandprior | thisandfuture )> 6.22. relatedto Property Name: relatedto Purpose: The property is used to represent a relationship or reference between one calendar component and another. Description: The property value consists of the persistent, globally unique identifier of another calendar component. This value would be represented in a calendar component by the "uid" property. By default, the property value points to another calendar component that has a PARENT relationship to the referencing object. The "RELTYPE" property parameter is used to either explicitly state the default PARENT relationship type to the referenced calendar component or to override the default PARENT relationship type and specify either a CHILD or SIBLING relationship. <!ELEMENT related-to(#PCDATA)> <!ATTLIST related-to reltype (parent | child |sibling)> 6.23. url property Name: url Purpose: This property defines a Uniform Resource Locator (URL) associated with the iCalendar object. Value: URI Description: This property may be used in a calendar component to convey a location where a more dynamic rendition of the calendar information associated with the calendar component can be found. This memo does not attempt to standardize the form of the URI, nor the format of the resource pointed to by the property value. If the 6.24. uid Property Name: uid Purpose: This property defines the persistent, globally unique Surendra Reddy [Page 35]
draft-ietf-calsch-scap-00.txt April 1998 identifier for the calendar component. Description: The uid itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. 6.25. exdate Property Name: exdate Purpose: This property defines the list of date/time exceptions for a recurring calendar component. Value: DATE-TIME ; The default value type for this property is DATE-TIME. The value type MAY be reset to DATE. Description: 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. 6.26. exrule Property Name: exrule Purpose: This property defines a rule or repeating pattern for an exception to a recurrence set. Value: RECUR Description: The exception rule, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. 6.27. rdate Property Name: rdate Purpose: This property defines the list of date/times for a recurrence set. Value : DATE-TIME ; The default value type for this property is DATE-TIME. The value type MAY be reset to DATE or PERIOD. Description: This property MAY appear along with the "rrule" property Surendra Reddy [Page 36]
draft-ietf-calsch-scap-00.txt April 1998 to define an aggregate set of repeating occurrences. When they both appear in an iCalendar object, the recurring events are defined by the union of occurrences defined by both the "rdate" and "rrule". The recurrence dates, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. <!ELEMENT rdate(#PCDATA)> <!ATTLIST rdate value (date|date-time|period) tzid NMTOKEN #REQUIRED> 6.28. rrule Property Name: rrule Purpose: This property defines a rule or repeating pattern for a recurring events, to-dos, or time zone definitions. Value: RECUR Description: The recurring rule, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. 6.29. trigger Property Name: trigger Purpose: This property specifies when an alarm will trigger. Value: duration ; The default value type is duration. The value type MAY BE reset to a DATE-TIME value type. Description: Within the "VALARM" calendar component, this property defines when the alarm will trigger. The default value type is duration, specifying a relative time for the trigger of the alarm. The default duration is relative to the start of an event or to-do that the alarm is associated with. The duration can be explicitly set to trigger from either the end or the start of the associated event or to-do with the "RELATED" parameter. A value of START will set the alarm to trigger off the start of the associated event or to-do. A value of END will set the alarm to trigger off the end of the associated event or to-do. Surendra Reddy [Page 37]
draft-ietf-calsch-scap-00.txt April 1998 <!ELEMENT trigger(#PCDATA)> <!ATTLIST trigger value (duration | date-time) related (start|end) tzid NMTOKEN #REQUIRED> 6.30. created Property Name: created Purpose: This property specifies the date and time that the calendar information was created in the calendar user agent. Value : DATE-TIME Description: The date and time is a UTC value. 6.31. dtstamp Property Name: dtstamp Purpose: The property indicates the date/time that the instance of the iCalendar object was created. Value: DATE-TIME Description: The value must be specified in the UTC time format. This property will assist in the proper sequencing of messages containing iCalendar objects. This property is different than the "created" and "lastmodified" 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. 6.32. lastmodified Property Name: lastmodified Purpose: The property specifies the date and time that the information associated with the calendar component was last revised. Surendra Reddy [Page 38]
draft-ietf-calsch-scap-00.txt April 1998 Value: DATE-TIME Description: The property value MUST be specified in the UTC time format. 6.33. sequence Property Name: sequence Purpose: This property defines the revision sequence of the calendar component used in a request. Value: INTEGER Description: This property is needed to properly handle the receipt and processing of a sequence of calendar components that have been delivered out of order. Such is the case for store-and-forward based transports. The first request is created with a sequence number of "0" (ASCII decimal 48). It is incremented each time the organizer or OWNER issues a revision to the request. 6.34. requeststatus Property Name: requeststatus Purpose: This property defines the status code returned for a scheduling request. Description: This property is used to return status code information related to the processing of an associated iCalendar object. The data type for this property is TEXT. The value consists of a short return status, a longer return status description, and optionally the offending data. The components of the value are separated by the SEMICOLON character (ASCII decimal 59). The short return status is a PERIOD character (ASCII decimal 46) separated 3-tuple of integers. For example, "3.1.1". The successive levels of integers provide for a successive level of status code granularity. <!ELEMENT requeststatus(#PCDATA)> <!ATTLIST requeststatus statcode NMTOKEN #REQUIRED statdesc NMTOKEN #REQUIRED> Surendra Reddy [Page 39]
draft-ietf-calsch-scap-00.txt April 1998 7. Security Considerations Since calendaring interoperability may involve the exchange of sensitive information, any calendaring interoperability mechanism must provide for encryption and authentication. Several techniques such as SSL and HTTP Access Authorization are available for use with HTTP as described in [3] and [4]. Without such techniques, SCAP clients and servers are wide open to forged or snooped meeting proposals or responses. 8. Calendar Object Specification - XML DTD <!DOCTYPE scap-1.0 [ <!-- Calendar Object Model - XML element definitions --> <!-- Author : Surendra Reddy --> <!-- Version 1.0 --> <!ELEMENT vcalendar ( vevent | vtodo | vjournal | vfreebusy | vtimezone )+)> <!ATTLIST vcalendar version PCDATA #REQUIRED prodid PCDATA #REQUIRED > <!ELEMENT vevent (attach*, attendee*, categories*, class?, comment*, contact*, created?, description?, (dtend|duration)?, dtstart, exdate*,exrule*, lastmodified?, location?, organizer?, priority?, rstatus?, related*, resources*, rdate*, rrule*, dtstamp, sequence?, status?, summary, transp?, uid, url?, recurid?)> <!ELEMENT vtodo (attach*, attendee*, categories*, class?, comment*, contact*, completed?, created?, description?, (dtend|duration)?, dtstart?, exdate*, exrule*, lastmodified?, location?, organizer?, percent?, priority, rstatus?, related*, resources*, rdate*, rrule*, dtstamp, sequence?, status?, summary, transp?, uid, url?, recurid?)> <!ELEMENT vjournal (attach*, attendee*, categories*, class?, comment*, contact*, created?, description, dtstart, dtstamp, exdate*, exrule*, lastmodified?, organizer?, rstatus?, related*, rdate*, rrule*, sequence?, summary, uid, url?, recurid?)> <!ELEMENT vfreebusy( freebusyreq|freebusyresp|busytime )> <!ELEMENT freebusyreq ( attendee, dtstamp, dtstart, dtend, uid, sequence?)> Surendra Reddy [Page 40]
draft-ietf-calsch-scap-00.txt April 1998 <!ELEMENT freebusyresp( attendee, dtstamp, freebusy, uid )> <!ELEMENT busytime (attendee, dtstamp, dtstart, dtend, freebusy)> <!ELEMENT vtimezone ( tzid, lastmodified?, tzurl?, (standard | daylight)) > <!ELEMENT standard ( comment*, dtstart, (rdate |rrule)?. tzname*, tzoffsetto, tzoffsetfrom)> <!ELEMENT daylight ( comment*, dtstart, (rdate | rrule )?, tzname*, tzoffsetto, tzoffsetfrom)> <!ELEMENT valarm ( alarmtype, (trigger, (duration, repeat)?, attach) | (description, trigger, (duration, repeat)?) | (attendee*, attach*, description, trigger, (duration, repeat)?, summary) | (attach, description?, trigger, (duration, repeat)?))> <!ELEMENT attach (#PCDATA) > <!ATTLIST attach encoding NMTOKEN #REQUIRED value CDATA #REQUIRED > <!ELEMENT categories (#PCDATA) > <!ATTLIST categories language NMTOKEN #REQUIRED > <!ELEMENT class (#PCDATA)> <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> <!ELEMENT percentcomplete(#PCDATA)> Surendra Reddy [Page 41]
draft-ietf-calsch-scap-00.txt April 1998 <!ELEMENT priority (#PCDATA)> <!ELEMENT comment(#PCDATA)> <!ATTLIST comment language NMTOKEN #REQUIRED > <!ELEMENT status (#PCDATA)> <!ELEMENT summary (#PCDATA) <!ATTLIST summary language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> <!ELEMENT completed (#PCDATA)> <!ELEMENT dtend(#PCDATA)> <!ATTLIST dtend value NMTOKEN #REQUIRED tzid NMTOKEN #REQUIRED> <!ELEMENT due(#PCDATA)> <!ATTLIST due value NMTOKEN #REQUIRED tzid NMTOKEN #REQUIRED> <!ELEMENT dtstart(#PCDATA)> <!ATTLIST dtstart value NMTOKEN #REQUIRED tzid NMTOKEN #REQUIRED> <!ELEMENT duration (#PCDATA)> <!ELEMENT freebusy(#PCDATA)> <!ATTLIST freebusy type (busy|free) bstat (busy|unavialable|trntative) <!ELEMENT attendee <!ELEMENT contact(#PCDATA)> <!ATTLIST contact language NMTOKEN #REQUIRED altrep NMTOKEN #REQUIRED> <!ELEMENT organizer(#PCDATA)> <!ATTLIST organizer cn NMTOKEN #REQUIRED sent-by NMTOKEN #REQUIRED Surendra Reddy [Page 42]
draft-ietf-calsch-scap-00.txt April 1998 dir NMTOKEN #REQUIRED> <!ELEMENT recurid(#PCDATA)> <!ATTLIST recurid value (date-time | date | period ) range ( thisandprior | thisandfuture )> <!ELEMENT relatedto(#PCDATA)> <!ATTLIST relatedto reltype (parent | child |sibling)> <!ELEMENT url (#PCDATA)> <!ELEMENT uid (#PCDATA)> <!ELEMENT exdate (#PCDATA)> <!ELEMENT exrule(#PCDATA)> <!ELEMENT rdate (#PCDATA)> <!ELEMENT rdate(#PCDATA)> <!ATTLIST rdate value (date|date-time|period) tzid NMTOKEN #REQUIRED> <!ELEMENT trigger(#PCDATA)> <!ATTLIST trigger value (duration | date-time) related (start|end) tzid NMTOKEN #REQUIRED> <!ELEMENT created (#PCDATA) <!ELEMENT dtstamp (#PCDATA)> <!ELEMENT lastmodified(#PCDATA)> <!ELEMENT sequence (#PCDATA)> <!ELEMENT csoperation(create|delete|select|rename)+ > <!ELEMENT create (#PCDATA) > <!ELEMENT delete (#PCDATA) > <!ELEMENT select (#PCDATA) > Surendra Reddy [Page 43]
draft-ietf-calsch-scap-00.txt April 1998 <!ELEMENT rename (from,to) > <!ELEMENT copy (from,to) > <!ELEMENT from (#PCDATA) > <!ELEMENT to (#PCDATA) > <!ELEMENT list ( allstores | allusers | curusr)+ > <!ELEMENT allstores (#PCDATA) > <!ELEMENT allusers (#PCDATA) > <!ELEMENT curusr (#PCDATA) > <!ELEMENT getcomponent(#PCDATA) > <!ELEMENT freebusyreq(csname+, dtstart,dtend)> <!ELEMENT csname (#PCDATA)> <!ELEMENT requeststatus(#PCDATA)> <!ATTLIST requeststatus statcode NMTOKEN #REQUIRED statdesc NMTOKEN #REQUIRED> ]> 9. References [CSCOS] F. Dawson, D. Stenerson, Internet Calendaring and Scheduling Core Object Specification, Internet Draft, draft-ietf-calsch-ical-00.txt, February 1997. [Alvestrand, 1995] H. T. Alvestrand, "Tags for the Identification of Languages." RFC 1766. Uninett. March, 1995. [Alvestrand, 1998] H. T. Alvestrand, "IETF Policy on Character Sets and Languages." RFC 2277, BCP 18. Uninett. January, 1998. [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 1997. [Bray, Paoli, Sperberg-McQueen, 1998] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml-19980210. Surendra Reddy [Page 44]
draft-ietf-calsch-scap-00.txt April 1998 http://www.w3.org/TR/1998/REC-xml-19980210. [Franks et al., 1997] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP : Digest Access Authentication" RFC 2069. Northwestern University, CERN, Spyglass Inc., Microsoft Corp., Netscape Communications Corp., Spyglass Inc., Open Market Inc. January 1997. [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997. [ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages." [ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times." [Leach, Salz, 1998] P. J. Leach, R. Salz, "UUIDs and GUIDs." Internet-draft, work-in-progress, February, 1998. ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt [Yergeau, 1998] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646." RFC 2279. Alis Technologies. January, 1998. [Bradner, 1996] S. Bradner, "The Internet Standards Process - Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. [Bray, Hollander, Layman, 1998] T. Bray, D. Hollander, A. Layman, "Name Spaces in XML" World Wide Web Consortium Working Draft, http://www.w3.org/TR/WD-xml-names. 10. Author's Address Surendra Reddy Oracle Corporation 500 Oracle Parkway M/S 6op3 Redwoodshores, CA 94065 Phone: +1(650) 506 5441 Fax: +1(650) 654 6205 Email: skreddy@us.oracle.com Surendra Reddy [Page 45]