Re: CAP / BEEP / XML / iCalendar - updated proposal

[sman@xxxxxxxxxxxx (Steve Mansour)]

Folks,

After thinking about some of the feedback on this, I think that the XML encoding, while harmless, is superfluous. At the meeting in Minneapolis, we were thinking along these lines:

ENCAPSULATION A

C: MSG 1 2 . 1234 123
C: Content-type: application/cap+xml
C:
C: <cap latency="3" action="">
C: <![CDATA[
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
...
C: END:VCALENDAR
C: ]]>
C: </cap>
C: END

The XML encapsulation is innocuous, but it adds nothing. Further, it tempts
us to move things out of the Application layer and into the Transport layer
(such as the command names, and attributes such as "latency" and "action"
-- undermining the transport/application separation and leading us down
slippery slopes.  Here is a simpler alternative (and yes, I know some
of you have been pushing for something like this all along :-) :

ENCAPSULATION B

C: MSG 1 2 . 1234 123
C: Content-type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
C: LATENCY:3
C: ACTION:ASK
...
C: END:VCALENDAR
C: END

The advantage of encapsulation B is that it represents exactly the same
content as encapsulation A, but it uses one rather than two encapsulations
and there are no hints about the calendaring commands in the transport.
We could substitute *any* transport.

Can anyone suggest why we would want to use encapsulation A rather than B ?

Are there any objections to moving forward with encapsulations as specified in B ?

-Steve

begin:vcard 
n:Mansour;Steve
tel;work:408-276-4268
x-mozilla-html:FALSE
org:;AOL / Netscape
adr:;;;;;;
version:2.1
email;internet:sman@xxxxxxxxxxxx
title:Director of Engineering
fn:Steve Mansour
end:vcard