Calendar Sharing Use Case

["Drummond Reed" <drummond.reed@cordance.net>]

For reference on this week's TC call, the following is a plain text version
of the Calendar Sharing use case (also posted at
http://xrixdi.idcommons.net/moin.cgi/XdiUseCases_2fCalendarSharing). 

== XDI Use Case :: Calendar Sharing ==
 * '''Level:''' Kite

=== Description ===
This is the general use case of sharing calendar entries (appointments or
meeting requests) among individuals or groups. Currently this is supported
by many enterprise groupware systems such as Lotus Domino or MS Exchange,
however there is no Internet-wide standard for calendar sharing across all
types of applications, devices, and domains. (Note that the evolution from
enterprise calendar sharing to Internet calendar sharing is precisely
analogous to the evolution from enterprise email systems to Internet email.)

=== Actors ===
 * Calendar Data Authorities (Calender DAs - owners/managers of calendar
data).
  * Can be either an individual calendar owner or a group calendar manager
(special requirements for group calendar sharing will be developed in a
subsequent use case if necessary).
  * Can be represented by delegated XDI calender service providers (XSPs)
doing remote hosting of the authority's calendar sharing service or can
operate the service directly (similar to the option today to outsource or
natively host your own DNS, email, or Web servers).

=== Pre-Conditions ===
 1. Each Calendar Authority has a network calendar sharing service and at
least one address identifying this service.
 1. Each Calendar Authority has established a set of policies governing
calendar data sharing.

=== Steps / Activities ===
 1. Calendar Authority A sends an appointment request to the calendar
sharing service of Calendar Authority B.
 1. The calendar sharing service of Calendar Authority B receives the
request and acts on it according to the calendar data sharing policies of
Calendar Authority B to determines the next action:
  a. The request can be denied.
  a. The request can be delegated to a human or another application for a
decision.
  a. The request can automatically be accepted.
 1. When the decision is made, Calendar Authority B sends a response to
Calendar Authority A.
  a. If the request was accepted, the appointment data is now shared and
linked by an appropriate link contract.
  a. If the request was modified, it must be processed by Calendar Authority
A according to its own policies. Negotiation may continue for as many rounds
as are permitted under the policies of the two authorities.
  a. If the request was denied, a reason may or may not be given depending
on the policy of Calendar Authority B.

=== Post-Conditions ===
 * If the request was accepted and the data sharing link created, the
associated policies can dictate how that data can be further modified. For
example, the policy may allow either party to request a change to the
time/date, subject, location, or other attributes of the appointment.

=== Variations ===
 * Calendar Authority A may wish to query Calendar Authority B for free/busy
times before proposing an appointment. This form of a query may require an
associated policy for authorization, as free/busy data can also be
sensitive.
 * If the two authorities did not have a previous data sharing relationship,
the initiation of the relationships may involve the sharing of other data,
such as contact data. This may require additional policies.
 * If the two authorities already had an data sharing relationship, the
necessary relationship data may already be shared, and the steps above may
only apply to sharing a new type of data (an appointment).

=== Issues / Key Requirements ===
 * When contrasted with address book sharing, calendar sharing may involve
much more frequent additions and changes of data.
 * Calendar sharing highlights the need for bi-directional data sharing
relationships and shared authority over data, since the norm is likely to be
that either party may request changes the data (i.e., to revise a previously
scheduled appointment).
 * With automated machine-to-machine communications, calendar sharing bleeds
over almost into "presence". For example, it is feasible for phone users to
use automated calendar sharing to "ping" another user and "get in the queue"
for a phone call. This is similar to the way IM is being used to do call
"pre-flight" among frequent communicators today.

=== Security Considerations ===
 * Calendar sharing often involves very sensitive data and thus may
frequently requires secure communications between the calendar sharing
services.

=== Privacy and Other Data Protection Considerations ===
 * In many cases (particularly in business interactions), calendar sharing
policies must address the privacy of the data.
 * Aggregate calendar data may be much more sensitive than individual
appointments.
 * Calendar free/busy queries will also need to be addressed by privacy
policies.

=== Links and Resources ===
 * A more detailed description of how XDI might apply to calendar sharing is
included in the
[http://www.oasis-open.org/committees/download.php/5115/wd-xdi-intro-white-p
aper-2004-01-20.pdf OASIS XDI TC introductory white paper].
 * iCal (Internet Calendar), also called vCal, is an IETF Working Group at
http://www.imc.org/ietf-calendar/. More information is available at the
Personal Data Interchange section of the Internet Mail Consortium website at
http://www.imc.org/pdi/. 

=== Contributors ===
 * DrummondReed