Internet-Draft 2/6/97
draft-ietf-calsch-cih-00.txt Expires 6 months from above date
Calendaring Interoperability over HTTP (CIH)
Abstract
Calendaring Interoperability over HTTP (CIH) is a technique
for 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 is a tentative exploration of whether CIH is
feasible and what the pros and cons are relative to a brand
new protocol like the Calendaring Interoperability Protocol
(CIP). The primary benefit of CIH over CIP and motivation
for this project is that we avoid implementing a whole new
protocol, such as writing and debugging the protocol,
convincing vendors to write new code to support it, and then
convincing users to deploy it.
Table of Contents
Abstract ..................................................1
Table of Contents .........................................1
1.0 Introduction ..........................................1
2.0 Overview of CIH .......................................2
2.1 Performing Basic CIH Operations ......................2
2.2 Mapping an Attendee Address to a URL for CIH .........3
3.0 Pros and Cons of CIH (vs CIP) .........................3
3.1 Performance Concerns .................................3
4.0 Security Considerations ...............................4
5.0 References ............................................4
6.0 Open Issues ...........................................4
7.0 To Be Done ............................................5
8.0 Author's Address ......................................5
1.0 Introduction
The Internet Calendaring and Scheduling Core Object
Specification (iCalendar) [1] describes a way to represent
calendaring and scheduling objects and verbs as MIME
objects. This includes distributing and responding to events
and todos and sending free time queries and responses. One
of the most interesting parts of iCalendar(and probably one
of the best) is that these objects can include a Profile
property that indicates what action should be performed
(proposing an event, cancelling one, changing one,
responding to one, etc.). This allows the objects to be sent
around by email and transferred into scheduling systems,
either manually or by integrating the scheduling systems
with the email system.
1
Internet-Draft 2/6/97
draft-calsch-cih-00.txt Expires 6 months from above date
However, there are many times when email is not an ideal
transport for calendaring and scheduling. For instance,
email delivery can be slow and sometimes unreliable.
Gateways can mangle messages. Users can fail to check their
email for long periods of time. Most email systems will
require manual effort to transfer scheduling info from email
to the scheduling system and back. Many scheduling
operations can and should be performed better with a direct,
real-time connection between scheduling systems.
For these reasons, a protocol that allows iCalendar objects
to be exchanged in real time would be ideal. A simple
protocol will do. We're just exchanging MIME objects. The
details of the object format and the actions implied by the
objects (date syntax, attendee list, etc.) are considered in
the iCalendar spec.
Several protocols have been suggested to address this
problem. The CIP (Calendaring Interoperability Protocol) [2]
is a simple protocol with a few verbs that correspond to the
operations necessary to accomplish calendaring
interoperability. HTTP is also being considered for this
role and that is the focus of this document.
This document provides a tentative exploration of whether
Calendaring Interoperability over HTTP (CIH) is feasible and
what the pros and cons are relative to a brand new protocol
like the CIP.
2.0 Overview of CIH
CIH uses the overall architecture of CIP, but reimplements
it using a subset of the HTTP 1.1 protocol specification
[3]. CIH servers are HTTP servers and therefore must meet
all requirements for HTTP servers laid out in the HTTP 1.1
specification. CIH is merely a convention which describes
how certain HTTP commands should be handled when certain
MIME content types are used.
2.1 Performing Basic CIH Operations
All CIH operations are performed by using the HTTP POST
command to send MIME objects from the client to a specified
URL on the server and receive MIME objects in the response.
The MIME objects in question are those described by the
iCalendar spec and their semantics and syntax are described
thoroughly in that document.
HTTP is used in this context mostly as a real-time transfer
mechanism for MIME objects. Since its capabilities are a
superset of those provided by SMTP email, this does not
require significant changes to the iCalendar spec.
2
Internet-Draft 2/6/97
draft-calsch-cih-00.txt Expires 6 months from above date
2.2 Mapping an Attendee Address to a URL for CIH
The default value of an attendee as defined in iCalendar is
an RFC 822 address (that is, user@hostname). While iCalendar
allows the value to have other data types, such as URL, it
is desirable to have an easy way to map a single RFC 822
address into a URL that can be used for CIH. For the address
hanna@world.std.com, the CIH URL is
http://cih.world.std.com/hanna. The algorithm is to prepend
cih. to the host name and use the user name as an abs_path.
If this generates an invalid URL or an error occurs when CIH
communications are attempted, email communication SHOULD be
used.
A few notes here. First, this does not mean that all URLs
that support CIH must have this form. It just provides a
convenient method for mapping an RFC 822 address into an
HTTP URL for use with CIH. Second, if a better scheme
emerges for server location (SLP or whatever), we can
support that and provide backward compatibility with this
scheme via redirects.
3.0 Pros and Cons of CIH (vs CIP)
The primary benefit of CIH over CIP and the motivation for
this project is that we avoid implementing a whole new
protocol, such as writing and debugging the protocol,
convincing vendors to write new code to support it, and then
convincing users to deploy it. There are three phases to
this benefit: definition, implementation, and deployment.
Some would argue that defining CIH will be easier than
defining a whole new protocol. This is not clear, as there
is also a counter-argument that HTTP is so complicated that
defining CIH will be quite a task.
For vendors with lots of HTTP experience and code,
deployment of CIH will be easier than CIP. For vendors
without much HTTP experience, CIH will be more complex than
CIP and probably take more time to implement, even if HTTP
code can be licensed and integrated into their products.
For deployment, the balance is clearly in favor of CIH.
Users and administrators are already familiar with HTTP and
a great deal of infrastructure has been built up to support
HTTP already. Problems may arise, however, if CIH uses a
subset of HTTP or takes advantage of obscure or cutting-edge
features of HTTP that aren't widely implemented. These is
also a risk of customer backlash against using HTTP for a
purpose different from its original intent.
3.1 Performance Concerns
3
Internet-Draft 2/6/97
draft-calsch-cih-00.txt Expires 6 months from above date
Concerns have been raised that CIH will be substantially
slower than CIP. This section provides some of the arguments
pro and con.
While HTTP 1.0 is a connectionless protocol, HTTP 1.1 uses
persistent connections by default. This avoids the overhead
associated with bringing up and shutting down TCP
connections all the time.
Although HTTP 1.1 uses persistent connections, it is still a
stateless protocol in that each request is considered
without regard to the requests that preceded it (unless
cookies are used). The stateful nature of CIP can allow it
to optimize some operations by establishing a state once and
then performing several commands. However, it is not clear
that this will provide substantial performance improvements.
In the area of authentication and encryption, SSL avoids
reauthentication with every request.
Several HTTP features, such as compression via content
codings may provide sophisticated methods of boosting
throughput and therefore performance over CIP.
4.0 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, CIH clients and servers are wide
open to forged or snooped meeting proposals or responses.
5.0 References
[1] F. Dawson, D. Stenerson, _Internet Calendaring and
Scheduling Core Object Specification_, Internet Draft,
draft-ietf-calsch-ical-00.txt, February 1997.
[2] A. Ganguly, S. Hanna, P. O'Leary, B. Spencer,
_Calendaring Interoperability Protocol_, Internet Draft,
draft-ietf-calsch-cip-00.txt, November 1996.
[3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
Berners-Lee, _Hypertext Transfer Protocol_, RFC 2068.
[4] A. Frier, P. Karlton, P. Kocher, _The SSL Protocol
Version 3.0_, Internet Draft, draft-ietf-tls-ssl-version3-
00.txt, November 1996.
6.0 Open Issues
Define iCalendar objects to be used in CIH responses (other
than FREE-BUSY/REPLY). This will have the benefit of
4
Internet-Draft 2/6/97
draft-calsch-cih-00.txt Expires 6 months from above date
allowing responses (i.e. operation confirmations) by email
if that's desired.
Should have a non-destructive way to confirm that a given
URL supports CIH before you start PUTting things to it.
Otherwise, you might just be dumping things in a directory
on an HTTP server. Perhaps a GET that is expected to return
a certain value.
7.0 To Be Done
Add examples and lots more detail.
8.0 Author's Address
Steve Hanna
On Technology Corporation
hanna@world.std.com
(617)
692-3153
Anik Ganguly
OnTime
Campbell Services Inc.
http://www.ontime.com
Datatracker
Report a datatracker bug
draft-ietf-calsch-cih-00
None
| Document | Document type |
Expired Internet-Draft
(calsch WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Author |
Steve Hanna
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |