One document matched: draft-niemi-sipping-cal-events-01.txt
Differences from draft-niemi-sipping-cal-events-00.txt
Network Working Group A. Niemi
Internet-Draft Nokia Research Center
Expires: September 7, 2006 March 6, 2006
Session Initiation Protocol Event Packages for Calendaring
draft-niemi-sipping-cal-events-01
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 September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 September 7, 2006 [Page 1]
Internet-Draft SIP Calendar Events March 2006
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 September 7, 2006 [Page 2]
Internet-Draft SIP Calendar Events March 2006
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Niemi Expires September 7, 2006 [Page 3]
Internet-Draft SIP Calendar Events March 2006
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.
Niemi Expires September 7, 2006 [Page 4]
Internet-Draft SIP Calendar Events March 2006
Calendar Watcher: a SIP user agent responsible for issuing
subscriptions and processing notifications of calendar events.
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
Niemi Expires September 7, 2006 [Page 5]
Internet-Draft SIP Calendar Events March 2006
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
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 September 7, 2006 [Page 6]
Internet-Draft SIP Calendar Events March 2006
.----------. .--------. /--------\
|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 September 7, 2006 [Page 7]
Internet-Draft SIP Calendar Events March 2006
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|
+-------------+ +----------------+
Niemi Expires September 7, 2006 [Page 8]
Internet-Draft SIP Calendar Events March 2006
Figure 2: Calendar Addressing
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 September 7, 2006 [Page 9]
Internet-Draft SIP Calendar Events March 2006
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 September 7, 2006 [Page 10]
Internet-Draft SIP Calendar Events March 2006
"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
calendar servers per domain, they all need to install an identical
subcription with the subscriber.
Niemi Expires September 7, 2006 [Page 11]
Internet-Draft SIP Calendar Events March 2006
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
expiration measured in hours.
Niemi Expires September 7, 2006 [Page 12]
Internet-Draft SIP Calendar Events March 2006
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
entire entry is sent.
Niemi Expires September 7, 2006 [Page 13]
Internet-Draft SIP Calendar Events March 2006
OPEN ISSUE: Should 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 September 7, 2006 [Page 14]
Internet-Draft SIP Calendar Events March 2006
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 September 7, 2006 [Page 15]
Internet-Draft SIP Calendar Events March 2006
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?
Niemi Expires September 7, 2006 [Page 16]
Internet-Draft SIP Calendar Events March 2006
11. IANA Considerations
[Editor's note: Add IANA considerations here.]
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.
Niemi Expires September 7, 2006 [Page 17]
Internet-Draft SIP Calendar Events March 2006
[11] Dusseault, L., "Calendaring Extensions to WebDAV (CalDAV)",
draft-dusseault-caldav-10 (work in progress), February 2006.
[12] Rosenberg, J., "A Presence Event Package for the Session
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-07 (work in
progress), February 2006.
Niemi Expires September 7, 2006 [Page 18]
Internet-Draft SIP Calendar Events March 2006
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 September 7, 2006 [Page 19]
Internet-Draft SIP Calendar Events March 2006
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 (2006). 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 September 7, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 17:02:50 |