[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iRIP and CAP
pregen@xxxxxxxxxxxxxxxxxx wrote:
> Ok. That's what I needed to hear. I had only heard a couple of
> "Keep" the draft - and more "let it go away." One group says
> that most if not all the iRIP functionality is in CAP -
> therefore we don't need iRIP. The pieces that are not there
> should be in a "short doc" and John Stracke has volunteered to
> work on such a document. I can not speak for him - but watch
> for something soon.
OK, so here's the story: CAP already contains iTIP
functionality. All commands and responses are embedded in
iCalendars; while there are some CAP-specific commands (e.g.,
QUERY), the full set of iTIP is also available. The problem,
though, is that, for interdomain scheduling, you don't
necessarily want to expose your CAP server--it would be like
having to expose your IMAP server in order to accept SMTP
traffic. (Sure, some people do expose their IMAP or POP servers,
so their users can get in--but they have the choice; and they
have the ability to apply different security rules.) An iRIP
server would be more limited; it would only accept iTIP. So what
I did was to write up a profile for CAP, a subset which supports
only iTIP functionality. This way, we don't have to maintain two
full-sized protocols; moreover, a site can smoothly transition
their public server between full CAP and iTIP only.
I didn't call the subset iRIP, because of the possibility for
confusion. Instead, I called it CRISP: CAP Real-time iTIP-based
Scheduling Profile.
As it turned out, the profile was fairly easy; about all I had to
do was specify the capability set that makes a CAP server a CRISP
server. (I also had to define a new capability value of NONE for
a couple of mandatory features; but the CAP editors have said
they don't object to adding those to the CAP spec, if the WG
agrees.) The I-D is attached. The version number is -xx because
I can't submit it for publication until after the meeting, so we
might have to change it before the the -00 version.
--
/=================================================================\
|John Stracke | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |================================================|
|eCal Corp. |No matter how tempting the prospect of unlimited|
|francis@xxxxxxxx|power, I will not consume any energy field |
| |bigger than my head. |
\=================================================================/
Internet Engineering Task Force J. Stracke
INTERNET DRAFT eCal
draft-stracke-calsch-crisp-xx.txt August 2000
Expires: February 2001
CAP Realtime iTIP-based Scheduling Profile (CRISP)
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 docu-
ments 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 document and related documents are discussed on the calsch mail-
ing list.
2. Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
3. Abstract
This document sets forth a restricted profile of [CAP], one which
supports no operations beyond the scheduling functionality of [iTIP].
The motivation is to permit use of CAP's real-time iTIP functionality
without exposing the calendar access functionality (which may require
stricter security controls than iTIP).
Stracke [Page 1]
CRISP May 2000
4. Introduction
[iTIP] defines a scheduling protocol based on exchanging specially
formatted [iCalendar] messages. iTIP is defined to be independent of
transport protocol. At present, there is one standard binding of
iTIP to a transport protocol, [iMIP], which carries iTIP messages in
email. This is a useful base level capability (email can reach vir-
tually any user on the Net), but can involve considerable latencies.
A real-time binding for iTIP would be useful; it would permit appli-
cation developers to give users better feedback on the progress of
the iTIP operations.
Since CAP includes full iTIP functionality, one option would be to
permit full access to CAP; to schedule an event with a remote user,
one would then make a CAP connection to their CS. The problem is
that such a connection may be considered a security risk in some
organizations; even though the CS has ACLs to prevent the client from
performing non-iTIP operations, it would be better if client simply
could not attempt such operations. (It's as if mail administrators
were told that an SMTP server outside the firewall had to include
IMAP functionality as well.) Thus, this document defines a profile
of CAP, a subset which does not support non-iTIP operations.
5. Profile Definition
A CRISP server is a CAP server with the following capabilities:
* ITIPVERSION=1.0
* CAPVERSION=1.0
* CAR=NONE
* QUERYLEVEL=NONE
In addition, various AUTH capabilities are expected. Other capabili-
ties which apply to iTIP operations may be specified; e.g., MAXDATE
and MAXICALOBJECTSIZE.
Note that NONE is not a legal value for CAR or QUERYLEVEL in the cur-
rent draft of CAP. This will have to be resolved.
A CRISP server MUST NOT accept any iCalendar component which is not a
valid iTIP component.
6. Firewall Application
Clearly, it would be undesirable for an organization with a CAP
server to have a CRISP server implemented completely separately, but
Stracke [Page 2]
CRISP May 2000
having access to the same database. Such duplication would increase
development costs, maintenance costs, and security exposure. On the
other hand, it would be possible to build a CRISP server which han-
dles all operations by proxying them to the CAP server. Such a proxy
could be placed in the "no-man's-land" common in firewalls; the fire-
wall would permit CAP connections from the outside to the proxy, and
from the proxy to the internal CAP server. The proxy would review
all incoming iCalendar components and validate that they were legiti-
mate iTIP operations; no non-iTIP components would be forwarded to
the CAP server. Similarly, if necessary, the proxy might censor the
iTIP replies coming from the CAP server.
7. Security Considerations
The protocol defined in this document is a subset of [CAP], and
accordingly inherits all of CAP's security analysis. However, new
analysis does need to be done for the subset, especially since the
whole point of the subset is to address security concerns.
8. Author's Address:
John Stracke
Chief Scientist
eCal Corp.
Email: francis@xxxxxxxx
9. References
[iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport-
Independent Interoperability Protocol (iTIP)", RFC 2446, November
1998
[iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-Based Interop-
erability Protocol (iMIP)", RFC 2445, November 1998
[CAP] Mansour, Dawson, Royer, Taler, Hill, "Calendar Access Protocol
(CAP)", draft-ietf-calsch-cap-03.txt, July 2000. Work in progress.
[iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling Core
Object Specification (iCalendar)", RFC 2445, November 1998
Stracke [Page 3]