Network Working Group A. Niemi Internet-Draft Nokia Research Center Expires: January 13, 2006 July 12, 2005 Session Initiation Protocol Event Packages for Calendaring draft-niemi-sipping-cal-events-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Calendar sharing and scheduling enable a user to subscribe to receiving calendar information from other users' calendars as well as scheduling of various calendar events among a set of users. This memo defines Session Initiation Protocol (SIP) event packages for calendar sharing and scheduling. Niemi Expires January 13, 2006 [Page 1] Internet-Draft SIP Calendar Events July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Conventions and Terminology . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Short History of internet Calendaring . . . . . . . . . . 5 3.2 Advantages of SIP for Calendaring . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 5. Addressing a Calendar and Calendar Entries . . . . . . . . . . 8 6. Calendar Event Package Definition . . . . . . . . . . . . . . 9 6.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 9 6.2 Event Package Parameters . . . . . . . . . . . . . . . . . 9 6.3 SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 9 6.4 Subscription Duration . . . . . . . . . . . . . . . . . . 10 6.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 6.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 10 6.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 11 6.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 11 6.9 Handling of Forked Requests . . . . . . . . . . . . . . . 11 6.10 Rate of Notification . . . . . . . . . . . . . . . . . . . 12 6.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 12 7. Scheduling Event Package Definition . . . . . . . . . . . . . 12 7.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 12 7.2 Event Package Parameters . . . . . . . . . . . . . . . . . 12 7.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 12 7.4 Subscription Duration . . . . . . . . . . . . . . . . . . 12 7.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13 7.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 13 7.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 13 7.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 14 7.9 Handling of Forked Requests . . . . . . . . . . . . . . . 14 7.10 Rate of Notification . . . . . . . . . . . . . . . . . . . 14 7.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14 8. Publication Considerations . . . . . . . . . . . . . . . . . . 14 8.1 Calendar Sharing Event Package . . . . . . . . . . . . . . 14 8.1.1 PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . 14 8.1.2 Multiple Sources for Event State . . . . . . . . . . . 15 8.1.3 Event State Segmentation . . . . . . . . . . . . . . . 15 8.1.4 Rate of Publication . . . . . . . . . . . . . . . . . 15 8.2 Scheduling Event Package . . . . . . . . . . . . . . . . . 15 8.2.1 PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . 15 8.2.2 Multiple Sources for Event State . . . . . . . . . . . 15 8.2.3 Event State Segmentation . . . . . . . . . . . . . . . 16 8.2.4 Rate of Publication . . . . . . . . . . . . . . . . . 16 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1 Calendar Sharing . . . . . . . . . . . . . . . . . . . . . 16 9.2 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . 16 Niemi Expires January 13, 2006 [Page 2] Internet-Draft SIP Calendar Events July 2005 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1 Normative References . . . . . . . . . . . . . . . . . . . 17 12.2 Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Niemi Expires January 13, 2006 [Page 3] Internet-Draft SIP Calendar Events July 2005 1. Introduction Calendar sharing enables a user to subscribe to receiving information of a specific remote calendar. This calendar can represent the calendar entries of a particular user's daily schedule, or any other type of calendar information such as the release schedule of an open source software project. Several standards already exist or are works in progress in the area of calendaring. Most notably, the Internet Scheduling Core Object Specification (iCalendar) [1], the iCalendar Transport-Independent Interoperability Protocol (iTIP) [6] define the data format, and its binding to Internet email [7]. RFC 3265 [2] defines an event subscription and notification framework that can be used to subscribe to different types of events related to SIP systems. A publication counterpart, defined in RFC 3903 [3], allows for a SIP user agent to publish event state into a central compositor that then distributes this information to the subscribers of that event package. This memo defines two new event packages for calendaring events; the first allows sharing of calendar events and the second of scheduling events related to calendaring. Using these two event packages, we in effect define an iTIP mapping to SIP. 2. Document Conventions and Terminology 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 [4] and indicate requirement levels for compliant implementations. Here is a list of terminology used within this document: Calendar User Agent: a SIP user agent that acts on the behalf of the calendar user. Calendar Server: a SIP user agent responsible for accepting subscriptions and sending out notifications containing calendar data. Calendar Watcher: a SIP user agent responsible for issuing subscriptions and processing notifications of calendar events. Niemi Expires January 13, 2006 [Page 4] Internet-Draft SIP Calendar Events July 2005 3. Motivations 3.1 Short History of internet Calendaring Calendar sharing and scheduling applications date back several years. Especially in the enterprise domain, these applications have been commonplace for nearly a decade. Many enterprise collaboration tools have provided enterprise users with tools that enable calendar access, as well as the ability to schedule meetings and other calendar entries among the users. Tools based on proprietary protocols have provided very little interoperability, and generally have not allowed inter-organizational calendar access. Being able to schedule meetings across organizations necessitates the availability of: o Interoperable data formats o Interoperable sharing and scheduling protocols o Reasonable means of access control and channel security The availability of the first is all but guaranteed at present. The iCalendar format [1] and its predecessor, the vCalendar format [8] are nearly ubiquitous and supported by a majority of Personal Information Management (PIM) applications today. Also, recently an effort has been started to make a revision of the iCalendar standards. Some solutions for calendar sharing and scheduling have been available based on standard components, such as based on HTTP [9] and WebDAV [10] extensions. Recent efforts have proposed CalDAV [11] as a standard calendar access protocol based on WebDAV. Extending calendaring applications beyond a single administrative domain requires that the protocols allow reasonable means for user identification, authentication and access control. 3.2 Advantages of SIP for Calendaring Parallel to calendaring, other means for group collaboration and information sharing among users have emerged. Most notably, the SIP protocol has been defined as a means for peers to establish multimedia sessions among each other, as well as for sharing their online statuses (in the form of presence information [12]) including geolocation information [13]. The SIP events [2] provides as an extension to SIP tools that deal with subscribing to events, receiving notifications of and publication [3] of events related to a Niemi Expires January 13, 2006 [Page 5] Internet-Draft SIP Calendar Events July 2005 SIP resource. Authorization of this information sharing has also been defined using a generic authorization language. [14] There are obvious similarities between calendar sharing and for instance presence information sharing. Both are descriptive of the SIP resource (usually a person) and its activities and status. As is apparent in presence, having a single uniform identity to request this information as well as establish multimedia sessions and instant messaging bears many benefits: o It allows for asynchronous updates o It already inherently supports user authentication and fine- grained access control o It allows subscribing to calendars using an identifier that often already is associated with the user, i.e., a SIP Address-of- Record. 4. Overview of Operation This section presents an overview of the calendar and scheduling event packages. Figure 1 illustrates the logical architecture of the system. Especially worth noting that the Calendar Server component can equally well be a network-based node, or one colocated with the user's PIM application. The calendar server acts on behalf of the user, and can either accept SIP publications carrying calendaring and scheduling events, or be accessing a centralized calendar store. It is also possible to colocate the calendar server with another calendar access system, e.g., a CalDAV server. The role split would entail the CalDAV server taking care of calendar access, and the SIP calendaring server taking care of notification of calendar data changes. Niemi Expires January 13, 2006 [Page 6] Internet-Draft SIP Calendar Events July 2005 .----------. .--------. /--------\ |Calendar +---------+Calendar+----------|Calendar| |User Agent| |Server | |Database| `----------' `+--+---+' \--------/ ; : '. ,' : '. ,' : '-. ,' : '. ; : '. ,' : '. .--,'----. .---:----. .--'.----. |Calendar| |Calendar| |Calendar| |Watcher | |Watcher | |Watcher | `--------' `--------' `--------' Figure 1: Calendar Sharing Architecture When a subscriber wants to receive calendar information from a remote calendar, it creates a SUBSCRIBE request. This request identifies the resource whose calendar is requested in the Request-URI using a SIP or SIPS URI [5]. In addition, specific named calendars for the resource can be requested using the "name" Event header field parameter. The SUBSCRIBE request is routed via the SIP infrastructure, until it eventually arrives at a calendar server. The calendar server first authenticates the request. This is done using the authentication mechanisms defined in SIP. Next, the request is authorized by visiting a policy that the user has put in place for controlling the privacy setting for the calendar data. If authorized, the calendar server returns a 200 OK response. If the request could not be authorized at this time, a 202 Accepted response is returned, putting the subscription in "pending" state. Otherwise, the request is blocked and a 403 Forbidden response is returned. Immediately after that, the calendar server sends a NOTIFY request containing the latest calendar state. In case the authorization policy instructed blocking or politely blocking the subscription, or if the status was "pending", the request might contain bogus information. The SUBSCRIBE method creates a SIP dialog with a finite lifetime. Unless the subscriber periodically refreshes the dialog, it expires after a negotiated amount of time. To explicitly discontinue subscribing to a calendar, the subscriber issues a SUBSCRIBE request with zero expiry. This effectively removes the subscription. For the calendar event package, the notifications contain calendar entries in the form of 'text/calendar', and represent the calendar Niemi Expires January 13, 2006 [Page 7] Internet-Draft SIP Calendar Events July 2005 entries of the resource's calendar. For the scheduling event package, the notifications contain the outstanding scheduling requests for the resource. When a user wishes to schedule a calendar event with another user, it creates a PUBLISH request. The Request-URI of the request identifies the attendee using a SIP or SIPS URI. The request is routed using the SIP infrastructure until it arrives at a calendar server. The calendar server authenticates the request and authorizes it using an authorization policy. If the policy instructs the calendar server to accept the request, it returns with a 200 OK response, and optionally also adds the scheduling request into the user's calendar as tentative. If the request cannot be authorized at this time, a 202 Accpeted is returned, and the scheduling request is not added to the user's calendar. If the authorization policy instructed blocking the request, a 403 Forbidden response is returned. 5. Addressing a Calendar and Calendar Entries Each resource is identified using a SIP or SIPS URI. The same identity is used for subscribing to the resource's presence information as well as calendar information. The next level of addressing is done by identifying the event package. The final level of addressing a calendar is done using a name. For example, 'sip:alice@example.com' might have a set of calendars named "work", "home" and "hobbies". +--------+ |Resource| +---.----+ | V +-------'---------+ |Address-of-Record| +-------.---------+ | V +-----'-------+ |Event Package| +-----.-------+ | V +-----'-------+ +----------------+ |Calendar Name| -->|UID of the Entry| +-------------+ +----------------+ Figure 2: Calendar Addressing Niemi Expires January 13, 2006 [Page 8] Internet-Draft SIP Calendar Events July 2005 The final step in identifying a single calendar entry involves comparing the entry's Unique ID (UID) against the UIDs in the local calendar. Figure 2 illustrates the addressing scheme in SIP based calendaring. 6. Calendar Event Package Definition This section follows the rules of RFC 3265 [2] on defining new event packages. 6.1 Event Package Name The name of the calendar event package is "cal". This token appears in the Event header fields of SUBSCRIBE, NOTIFY and PUBLISH requests. Example: Event: cal 6.2 Event Package Parameters The SIP events framework allows event packages to create additional parameters that are carried in the Event header field. The calendar event package defines one such additional parameter called "name". Example: Event: cal;name=Work The "name" parameter further defines a specific, named calendar that represents a subset of the resource's full calendar. For example, users may want to separate their work and leisure time calendars. 6.3 SUBSCRIBE bodies As a calendar represents time, it can naturally span infinitely into the future, as well as in the past. The subscriber needs the ability to scope the subscription to a snapshot in time, e.g., a week in the past and three months into the future. This will help limit the amount of calendar information sent to the subscriber according to its preferences. A subscriber requests a calendar snapshot by including an event filter into the body of the subscribe request. In it, the subscriber specifies a window, relative to present time, that expresses how far the calendar is required to reach into the past and into the future when including data into the notifications. Niemi Expires January 13, 2006 [Page 9] Internet-Draft SIP Calendar Events July 2005 OPEN ISSUE: What filter language is appropriate here? Could iCalendar itself be used directly, or via an extension to iTIP? To request free/busy data, a special filter is included in the SUBSCRIBE request that includes an iTIP method for requesting the free/busy data. 6.4 Subscription Duration Changes to calendar data are relatively infrequent. At least if compared to other event types, such as the presence event [12]. Events are usually only triggered when calendar entries are added, removed or edited by a human user, which happens perhaps once per day on average. This depends on the calendar type, but using this approximation, the calendar subscriptions should have an expiration measured in hours or days. OPEN ISSUE: Free to suggest a better approximation. Therefore, the default expiration of a calendar subscription is one day, or 86400 seconds. 6.5 NOTIFY Bodies For the calendar event package, the body of the NOTIFY contains an iCalendar based calendar object, usually a collection of one or more calendar entries. Therefore, the default MIME type for the calendar event package is "text/calendar", which MUST be supported by all subscribers and notifiers. Additional MIME types MAY be supported. 6.6 Notifier Processing of SUBSCRIBE Requests Upon receiving a SUBSCRIBE request, the calendar server needs to authenticate the request, and apply its access control policy to the request. This authorization decision can be a complex one, taking into account the subscriber's asserted identity, time-of-day and other similar input. Ultimately, the decision results in either an "accept", a "block", a "polite-block" or "pend". "accept" results in the notifier accepting the SUBSCRIBE request, installing a subscription, and immediate generation of a NOTIFY request with the latest calendar state. Niemi Expires January 13, 2006 [Page 10] Internet-Draft SIP Calendar Events July 2005 "block" results in the notifier rejecting the SUBSCRIBE request, returning a 403 Forbidden response. "polite-block" results in a bogus subscription being installed. I.e., the calendar server accepts the subscirption with a 200 OK response, but actually reveals no meaningful information in subsequent notifications. "pend" results in the notifier accepting the SUBSCRIBE request with a 202 Accepted response, and put the subscriptioin in "pending" state. 6.7 Notifier Generation of NOTIFY Requests The calendar server MAY send a NOTIFY at any time. Typically one will be sent when a calendar entry is modified, added or deleted. The conditions for when NOTIFYs are sent and the amount of information delivered therein is subject to the authorization policy to specify. Only calendar changes are transmitted to the subscriber. When the content type of the NOTIFY request is 'text/calendar', the granularity by which state is segmented follows that of iCalendar format itself. That is, if a calendar entry is modified, the calendar entry is sent in entirety. OPEN ISSUE: additions and modifications to calendar entries are possible to be sent in this fashion (i.e., any received entry with a matching UID replaces an existing one), but there is no natural iCalendar scheme to indicate that an entry was deleted. 6.8 Subscriber Processing of NOTIFY Requests The NOTIFY request contains a collection of one or more calendar events, each uniquely identitied using the UID. The subscriber processes these notifications using a "replace" semantic. Each UID is compared against a (possible) set of local calendar entries, and any matching UIDs automatically replaces the existing entries. 6.9 Handling of Forked Requests This specification does not support a heterogenous set of calendar servers for a resource. In other words, forked SUBSCRIBE requests are only allowed to establish a single dialog. If there are multiple Niemi Expires January 13, 2006 [Page 11] Internet-Draft SIP Calendar Events July 2005 calendar servers per domain, they all need to install an identical subcription with the subscriber. 6.10 Rate of Notification Each event package needs to specify a recommended maximum rate for event notification. This specification recommends that notifications MUST be sent no more frequent than once per 60 seconds. 6.11 State Agents This specification defines the calendar server, which is a state agent acting on the user's behalf. It can collect information received from either using a SIP publications, or by accessing the user's calendar store. 7. Scheduling Event Package Definition 7.1 Event Package Name The name of the calendar event package is "sched". This token appears in the Event header fields of SUBSCRIBE, NOTIFY and PUBLISH requests. Example: Event: sched 7.2 Event Package Parameters This event package specification defines no additional Event header field parameters. 7.3 SUBSCRIBE Bodies The SUBSCRIBE requests MAY contain bodies that include subscription filters. No such filters are specified at this time for this event package. 7.4 Subscription Duration Scheduling events are relatively infrequent. At least if compared to other event types, such as the presence event [12]. Events are usually only triggered when meetings are scheduled, or replied to, canceled or coutered by a human user, which happens perhaps a few times per day on average. This depends on the calendar type, but using this approximation, the calendar subscriptions should have an Niemi Expires January 13, 2006 [Page 12] Internet-Draft SIP Calendar Events July 2005 expiration measured in hours. OPEN ISSUE: Free to suggest a better approximation. Therefore, the default expiration of a calendar subscription is an hour, or 3600 seconds. 7.5 NOTIFY Bodies The content type of notifications for the scheduling event package by default are 'text/calendar' using the iCalendar format. Each NOTIFY contains a collection of one or more iCalendar components, each containing an iTIP method. 7.6 Notifier Processing of SUBSCRIBE Requests Upon receiving a SUBSCRIBE request, the calendar server needs to authenticate the request, and apply its access control policy to the request. This authorization decision can be a complex one, taking into account the subscriber's asserted identity, time-of-day and other similar input. Ultimately, the decision results in either an "accept", a "block", or "pend". "accept" results in the notifier accepting the SUBSCRIBE request, installing a subscription, and immediate generation of a NOTIFY request with the latest scheduling events. "block" results in the notifier rejecting the SUBSCRIBE request, returning a 403 Forbidden response. "pend" results in the notifier accepting the SUBSCRIBE request with a 202 Accepted response, and put the subscription in "pending" state. 7.7 Notifier Generation of NOTIFY Requests The calendar server MAY send a NOTIFY at any time. Typically one will be sent when a new scheduling event is received. The conditions for when NOTIFYs are sent and the amount of information delivered therein is subject to the authorization policy to specify. Only changes in the scheduling "queue" are transmitted to the subscriber. When the content type of the NOTIFY request is 'text/ calendar', the granularity by which state is segmented follows that of iCalendar format itself. That is, if an entry is modified, the Niemi Expires January 13, 2006 [Page 13] Internet-Draft SIP Calendar Events July 2005 entire entry is sent. OPEN ISSUE: Shouĺd the scheduling events always contain full state? 7.8 Subscriber Processing of NOTIFY Requests The NOTIFY request contains a collection of one or more scheduling events, each uniquely identitied using the UID. The subscriber processes these notifications using a "replace" semantic. Each UID is compared against a (possible) set of local calendar entries, and any matching UIDs automatically replaces the existing entries. 7.9 Handling of Forked Requests This specification does not support a heterogenous set of calendar servers for a resource. In other words, forked SUBSCRIBE requests are only allowed to establish a single dialog. If there are multiple calendar servers per domain, they all need to install an identical subcription with the subscriber. 7.10 Rate of Notification Each event package needs to specify a recommended maximum rate for event notification. This specification recommends that scheduling notifications MUST be sent no more frequent than once per 5 seconds. 7.11 State Agents This specification defines the calendar server, which is a state agent acting on the user's behalf. It collects scheduling information received from either using a SIP publications, or by means of another scheduling system. 8. Publication Considerations 8.1 Calendar Sharing Event Package 8.1.1 PUBLISH Bodies By default, the PUBLISH contains 'text/calendar' with a collection of one or more calendar entries. Niemi Expires January 13, 2006 [Page 14] Internet-Draft SIP Calendar Events July 2005 8.1.2 Multiple Sources for Event State Naturally, calendars can be accessed by multiple user agents. It is very commonlplace to sometimes delegate authority to edit a calendar, e.g., when a secretary has access to his bosses calendar. It is up to the authorization policy to instruct that suitably authorized third parties can have access to a calendar. OPEN ITEM: If a single calendar is access using the SIP publication mechanism as well as some other calendar access protocol like CalDAV, problems arise. CalDAV includes features such as locking, which aren't available in the PUBLISH-based access. A real-world solution might be to combine e.g., CalDAV based calendar access and SIP based notification. Do we need SIP based calendar access or editing at all? 8.1.3 Event State Segmentation Event state segmentation is handled naturally by the iCalendar format. Namely, each calendar entry represents a segment, and is identified by the UID element. 8.1.4 Rate of Publication Each usage of the PUBLISH method should indicate a recommended maximum rate for publication. The maximum rate of publication for this package is once per 60 seconds. 8.2 Scheduling Event Package 8.2.1 PUBLISH Bodies The body of the PUBLISH request includes by default a 'text/calendar' MIME type. It represents an iCalendar object, and more specifically, MUST contain an iTIP method. 8.2.2 Multiple Sources for Event State In scheduling, multiple sources for event state are the norm. In theory, any user should be able to schedule calendar events with any other user. Therefore, the authorization policy for scheduling publications is by definition an open one, but care must be taken to counter spam and other similar threats. Suitably authorized third parties can have their scheduling Niemi Expires January 13, 2006 [Page 15] Internet-Draft SIP Calendar Events July 2005 publications accepted and in addition, already written into the target calendar as "tentative". This allows for easier scheduling when the required attendee is not online to actively manage her scheduling requests. 8.2.3 Event State Segmentation Event state segmentation is handled naturally by the iCalendar format. Namely, each calendar entry represents a segment, and is identified by the UID element. 8.2.4 Rate of Publication Each usage of the PUBLISH method should indicate a recommended maximum rate for publication. The maximum rate of publication for this package is once per 60 seconds. 9. Examples [Editor's note: Add example message flows here.] 9.1 Calendar Sharing 9.2 Scheduling 10. Security Considerations As calendaring data represents highly confidential information about a user, authenticating the requests to access it, and securing the transmission of the data is very important. SIP [5] defines a set of authentication mechanismsm which are usable in calendaring as well. Similar to presence and geolocation information, authorizing the calendar information is also very important. OPEN ISSUE: Since authorization is at the heart of calendar accessm should we start defining an authorization scheme right from the start? I.e., an XCAP usage for calendar authorization based on common-policy rule language? 11. IANA Considerations [Editor's note: Add IANA considerations here.] Niemi Expires January 13, 2006 [Page 16] Internet-Draft SIP Calendar Events July 2005 12. References 12.1 Normative References [1] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 12.2 Informative References [6] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998. [7] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message- Based Interoperability Protocol (iMIP)", RFC 2447, November 1998. [8] Internet Mail Consortium, "vCalendar - The Electronic Calendaring and Scheduling Exchange Format", http://www.imc.org/pdi/vcal-10.txt , September 1996. [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [10] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [11] Dusseault, L., "Calendaring Extensions to WebDAV (CalDAV)", draft-dusseault-caldav-06 (work in progress), May 2005. [12] Rosenberg, J., "A Presence Event Package for the Session Niemi Expires January 13, 2006 [Page 17] Internet-Draft SIP Calendar Events July 2005 Initiation Protocol (SIP)", RFC 3856, August 2004. [13] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), September 2004. [14] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-04 (work in progress), February 2005. Author's Address Aki Niemi Nokia Research Center P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 Email: aki.niemi@nokia.com Niemi Expires January 13, 2006 [Page 18] Internet-Draft SIP Calendar Events July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niemi Expires January 13, 2006 [Page 19]