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

From: "John Stracke" <[email-masked]>
Date: Mon, 25 Mar 2002 12:59:41 -0500

>I wanted to know what it would look 
>like if the application part was XML/XCS rather than iCalendar.

If by "XCS" you mean "the XML representation of iCalendar", then nobody 
knows, because we haven't defined an XML representation of iCalendar yet.

Anyway, why do you want to know? It's not important.

>It's to 
>clarify that I was asking what an encapsulation that used XCS rather 
>than iCalendar would look like.

You are drawing an illegitimate distinction.  The XML representation of 
iCalendar, if it is ever standardized, will be a transliteration of 
text/calendar; any VEVENT, say, represented in XML will still be 
iCalendar.  So the phrase "XCS rather than iCalendar" is not meaningful.

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|Linux: the Unix defragmentation tool.                   |
\========================================================/

---

From: "John Stracke" <[email-masked]>
Date: Mon, 25 Mar 2002 13:58:25 -0500

>So we are dropping the XML version of iCalendar?

We are not dropping it.  It does not exist.  It might exist at some point 
in the future, but not until we're done with CAP.  It is not in the WG 
charter.

There is actually contention over whether or not it ought to exist at all; 
a case can be made that creating an alternate rendering of the same data 
cannot improve interop, and will probably harm it.

/=========================================================\
|John Stracke                    |Principal Engineer      |
[email-masked]   |Incentive Systems, Inc. |
|http://www.incentivesystems.com |My opinions are my own. |
|=========================================================|
|Peace, justice, morality, culture, family, sport, and the|
|extinction of all other life forms!                      |
\=========================================================/

---

From: "Micah Gorrell" <[email-masked]>
Date: Mon, 25 Mar 2002 16:07:34 -0700

Yes thank you!

A lot of us (myself included) have already written a lot of code around the
iCalendar syntax.  I really don't want to have to do all of that again for
an xml version.  I'm not saying there is anything wrong with xml.  I'm just
saying there is no added benifit.

Micah

-----Original Message-----
From: "Steve Mansour" <[email-masked]>
To: "Gary Frederick" <[email-masked]>
Cc: "CalSched IETF" <[email-masked]>
Date: Monday, March 25, 2002 3:21 PM
Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal

>Yipes!  I would not want to promote that.  For better or worse, RFC2445 is
not XML
>based. We spent several years trying to get that RFC through. People have
built
>software expecting iCalendar syntax. To change CAP now and and promote the
use of
>XMLized icalendar would open up a huge can of worms, and it would be unfair
to people
>who have invested in iCalendar. Let's please not go there.  Such a move is
really out
>of the scope of CAP.
>
>-Steve
>
>Gary Frederick wrote:
>
>> Let me try again...
>>
>> Steve, you gave an example that used good ol iCalendar in the
>> application part of the message. I wanted to know what it would look
>>      ENCAPSULATION B - XCS version
>>
>>      C: MSG 1 2 . 1234 123
>>      C: Content-type: the correct type for xcs...
>>      C:
>>      C: <vcalendar>
>>      C: <method type='search' latency='3' />
>>      C: <action>ask</action>
>>      ...
>>      C: </vcalendar>
>>      C: END
>>
>> The above is NOT an attempt to show what the XML/XCS should be. It's to
>> Gary
>> Steve Mansour wrote:
>> > Gary Frederick wrote:
>> >>What would the XML version of encapsulation B look like?
>> >
>> >
>> > There's no need for an XML encapsulation. We MUST have an iCalendar
encapsulation
>> > because that's how our application data is defined. The point of B was
to show
>> > that the iCalendar encapsulation is the only one needed.
>> >
>> > -Steve
>> >
>> >
>> >>
>> >>Gary
>> >>
>> >>Steve Mansour wrote:
>> >>
>> >>>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="ask">
>> >>>    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
>> >>>
>> >>
>

---

From: [email-masked]
Date: Tue, 26 Mar 2002 00:13:22 -0500

We are dropping the XML language in CAP (it was there to support BEEP but 
we've determined it's not needed).

Gary Frederick <[email-masked]>
Sent by: [email-masked]
03/25/02 13:05

        To:     CalSched IETF <[email-masked]>
        cc: 
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal

Gee, I must have missed that e-mail.

Gary

Doug Royer wrote:
> NONE  - use text/calendar ONLY.
>

---

From: "John Stracke" <[email-masked]>
Date: Tue, 26 Mar 2002 11:04:30 -0500

>If the other tasks are still on 
>the list, it could be a problem if all we do is focus on CAP???

The dates are just goals.  Getting CAP right is more important than 
getting other stuff done fast.

/==============================================================\
|John Stracke                    |Principal Engineer           |
[email-masked]   |Incentive Systems, Inc.      |
|http://www.incentivesystems.com |My opinions are my own.      |
|==============================================================|
|No matter how subtle the wizard, a knife in the shoulderblades|
|will cramp his style.                                         |
\==============================================================/

---

From: [email-masked]
Date: Tue, 26 Mar 2002 11:20:28 -0500

I agree.  We need to accomplish our goals, but not at the expense of CAP.

"John Stracke" <[email-masked]>
Sent by: [email-masked]
03/26/02 11:04

---

From: [email-masked]
Date: Tue, 26 Mar 2002 11:40:00 -0500

Hi Gary.  An updated charter is in the works.  We, like many groups, are 
behind in getting it updated. The dates do need to be renewed/adjusted. 

And yes, we have all those other things to work on, including updating 
iCalendar, iTIP and iMIP with things we find from interoperability testing 
- something we are working on as well. 

I think what we mean by focus on CAP is just that.  We need to get the 
draft to last call - if we could get other volunteers we can do all the 
things that are on the milestones.  It's hard to do when you only have 
about 7 people who are actively working on items.  I know Shannon is 
helping with the iCalendar stuff, but CAP is really big and it needs all 
the help we can get.  We've solicited on the list often.  The Steltor 
people have been great in stepping in to help out - as have all our 
volunteers.  If we can keep the notes to the list focused, it makes it 
easier for those who have agreed to help to keep on top of what is 
happening.  100 or more notes a day does not make it easy - unless the 
notes are relevant and concise. 

Actually, we need to figure out what to do with vCard and vCalendar. 
Someone asked me where the home was for vCard.  I'm not sure, but our 
group is a likely candidate unless some other group thinks it belongs with 
them.  Not sure.

Hope that helps.

03/26/02 10:12

        To:     [email-masked]
        cc:     CalSched IETF <[email-masked]>, John Stracke 
<[email-masked]>, [email-masked]
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal

Thanks!

As I read the charter, the next things are:
   Jul 01   Request last call on Guide to Internet Calendaring
   Jul 01   Submit Internet-Draft on Guide to Internet Calendaring for
              consideration as a Proposed Standard
   Jul 01   Submit revisions for Internet-Draft for iCalendar, iMIP and 
iTIP
   Jul 01   Submit revisions for Internet-Draft for Calendar Access 
Protocol

I understand that you adjusted the milestones and that CAP may be the 
only thing on the adjusted milestones. If the other tasks are still on 
the list, it could be a problem if all we do is focus on CAP???

Gary

[email-masked] wrote:
> 
> The charter can be found at 
> http://www.ietf.org/html.charters/calsch-charter.html.  An updated 
> charter with adjusted milestones has been sent to the secretariet for 
> update.

---

From: "John Stracke" <[email-masked]>
Date: Tue, 26 Mar 2002 12:10:45 -0500

>Someone asked me where the home was for vCard.

It doesn't really have one at this point; it looks like RFC-2425 and 2426 
were developed by a WG called ASID, but ASID doesn't exist any more.  (Or 
they might have been developed by individuals who got help from the ASID 
group; it's not clear to me.) It doesn't particularly need a WG as long as 
it's stable, after all; and it's got a registration process defined for 
small-scale evolution.

>I'm not sure, but our
>group is a likely candidate unless some other group thinks it belongs
>with them.  Not sure.

I would think vCard would fall more closely to one of the LDAP working 
groups; it's closer to their expertise.  The affinity between vCard and 
[vi]Calendar is more a historical artifact than a technical relationship.

/=================================================================\
|John Stracke                    |Principal Engineer              |
[email-masked]   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|"How can one conceive of a one party system in a country that has|
|over 200 varieties of cheese?" --Charles de Gaulle               |
\=================================================================/