Subject: Extend CAP use of iCalendar?

From: Eric Busboom <[email-masked]>
Date: Wed, 14 Feb 2001 11:23:22 -0800 (PST)

In the CAP draft ( draft-ietf-calsch-cap-03.txt ) there are several
examples of data returned from the server that is similar in content and 
form to iCalendar components. For example:

   C: CAPABILITY
   S: 2.0
   S:CAPVERSION=1.0
   S:AUTH=KERBEROS_V4
   S:AUTH=DIGEST_MD5
   S:AUTH=ANONYMOUS

or: 

   C: AUTHENTICATE KERBEROS_V4
   S: AmFYig==
   C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
   S: or//EoAADZI=
   C: DiAF5A4gA+oOIALuBkAAmw==
   S: 2.0
   S: .
   S: Content-Type:text/calendar; method=REQUEST; charset=US- ASCII
   S: Content-Transfer-Encoding: 7bit
   S:
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/CAPserver//EN
   S: VERSION:2.1
   S: IDENTITY=[email-masked]
   S: CAPVERSION=1.0
   S: ITIPVERSION=1.0
   S: AUTH=KERBEROS_V4
   S: AUTH=DIGEST_MD5
   S: CAR=CAR-FULL-1
   S: MINDATE=19700101T000000Z
   S: MAXDATE=20370201T000000Z
   S: END:VCALENDAR
   S: .

The second one hints at using iCalendar for transfering the data, but it
is not quite there. Is this a typo? Should the VCALENDAR have CAPVERSION
and ITIPVERSION and AUTO properties instead of those lines with the
"="?

Using real iCalendar format components for these data would make
implementation much easier. Ditto with the response codes:

Is there a way to make something like:

   C: CALIDEXPAND cap://cal.example.com/calid14
   S: 2.0 cap://cal.example.com/calid14
   S: cap://cal.example.com/calid2
   S: cap://cal.example.com/calid5
   S: cap://cal.example.com/calid66
   S: .

use an iCalendar style component instead?

eric.

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Feb 2001 15:00:15 -0500

> implementation much easier. Ditto with the response codes:

This sounds like a good idea.  The only reservation I have is that it might
be best to keep the iCalendar objects at a higher level.  At the moment, we
have a clean separation: there's a transfer protocol carrying iCalendar; no
iCalendar objects appear except the ones which are being carried.  If
iCalendar objects are used to carry authentication information, it may
become harder to perform security analyses--is this iCalendar object that
you're looking at a correct part of authentication, or is it a piece of
calendar data that got exposed before authentication was complete?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |The Player's Litany: The Wind is the Storm, and|
[email-masked]|the Storm is Data, and the Data is Life.       |
|                |--Daniel Keys Moran                            |
\================================================================/