Subject: XML and CAP discussion

From: "Frank Dawson" <[email-masked]>
Date: Fri, 26 Feb 1999 12:36:45 -0500

A very logical approach to addressing inclusion of XML in the CAP discussion is as follows:

1. The MANDATORY iCalendar encoding required for conformance to the initial CAP specification is that defined in RFC 2445 and as augmented by the CAP specification, itself.

2. Using a "capabilities" feature in a CAP server, a CUA can determine if the CAP server supports the additional, but optional, iCalendar XML encoding. See the recent iCalendar XML DTD document posted to the IETF Internet-Drafts by Dawson/Reddy/Royer) for an idea of what this would look like.

3. If the CUA sends the iCalendar XML encoding, it MUST be sent as a MULTIPART/ALTERNATIVE MIME entity. The ordering of the MIME entities would be any other encodings first (such as a non-standard pretty TEXT/PLAIN rendition), then the experimental XML encoding, then the standard RFC 2445 iCalendar encoding.

This way, implementors wishing to experiment with an XML encoding can do so, yet still interoperate with the current, STANDARD format defined by RFC 2445.

I am suprised that this was not more vocally advocated by folks on the list. This is my understanding of the general consensus at the last CAP design meeting.

What do others think of this?

- - Frank Dawson

---

From: [email-masked]
Date: Sun, 7 Mar 1999 21:53:35 -0500

John, we agree.  However, typical WGs run around 18 months so 3 years is
already a long duration. That's kind of why the group is being asked to
deliver something.  Remember, this is the first version of this draft.
There is alreay work in progress to start on the next draft.  Also, there
needs to be some vendor implementations and that takes time so we really
need that draft soon.

John Stracke <[email-masked]> on 03/07/99 02:46:16 PM

 To:      [email-masked]                               
                                                              
 cc:      (bcc: Pat R Egen/Egen Consulting/01)                

 Subject: Re: XML and CAP discussion                          

Doug Royer wrote:

> The BIG issue is that if we do not have a CAP draft out by the
> summer meeting - the working group CALSCH could be closed down.

Why is that? I realize the WG has been going for nearly 3 years; but it's
not
as if no progress has been made.  If the WG were being delayed by lack of
consensus over fundamentals, that'd be one thing; but it seems to me that
that's not the case; most of the work has been done, and we're on the home
stretch.  No?

I've been working with the IETF for only about a year now, so maybe I'm
just
missing something about the IETF process; but, intuitively, it wouldn't
make
a lot of sense to shut down a WG that's close to completion.  People would
still need a standard, so they'd go off and do it somewhere else; the
protocol that was produced wouldn't have the benefits of IETF oversight;
and
the people who got the rug pulled out from under them would be leery of
working with the IETF in the future.  Nobody wins.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: [email-masked]
Date: Mon, 08 Mar 1999 16:23:54 GMT

Doug replied:
>Its is NOT early in the race. The iCalendar objects are already an RFC,
>as in iTIP, and iMIP. There are already products shipping using
>implementations based on the RFC's. We can't just abandon them.

  Hear, hear!  Ive been swapped out on other business for the past 2 
months so Ive only lurked at best.  With the current amount of time, 
sweat, frequent flyer miles and maybe even blood invested in gettting to 
RFC status w/iCalendar, iTIP and iMIP we are not 'early' in any thing.  I 
havent heard the CAP editors arguments for/against this mid-stream 
switch/change so Ill just state my own views.

  I wont buy any argument that XML is a standard and that iCalendar is not 
(or is not as good).  W/all the cycles that has been collectively put into 
getting iCalendar to RFC (but not XML that Ive seen), that wont hold 
water.

  If there is a proposal afoot to create some XML DTD that can 
co-represent iCalendar data/intent then a few options open up.

1: Leave it for later and just focus on iCalendar based CAP.
2: Consider how to tweak/extend the architecture to allow multiple content 
based C&S (ie: mixed or negotiated use of iCal and XML)
3: Build CAP such that it obsoletes iCalendar (eventually) in favor of 
XML.

There could be a few other flavors of options but Id need more caffine to 
clearly deliniate them.  In any case, as the CAP effort is going to take 
some time to complete (IMHO), I think that either 1 or 2 is a better 
choice.  #3 is much like saying that we want to create some new SGML-like 
language to replace HTML so that we can be 'standard'.  (After all both 
iCal and HTML are RFCs but the new stuff isnt).  This option is not as 
desireable as a vendor since I want to get a product done and out to 
customers before I retire.  If we can build what the customers want w/the 
current resources (RFCs) then lets do it.  If we think that the current 
resources are indadequate then what will it take to get the foundation we 
need?

Pat asked:
>There is a proposal on the table to have an
>addendum added to the document that show how to implement CAP using XML.
>However, it would be with the understanding that the underlying MUST 
syntax
>would be ICAL-based.  Then, once the draft was submitted, CAP version 2
>would be started and the direction for that draft would be towards XML,
>which by that time has had time to evolve itself.

  I was with you up until that last line.  Perhaps if you or the pro-XML 
CAP Editors could explain why iCalendar is insufficient for our needs it 
may help me (and others) make up their minds...  (Im still taking the KISS 
and 'If it ain't broke, why fix it?' line of thinking so make it good!)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...