Subject: RE: Accelerated CAP (draft-2)

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Wed, 16 Sep 1998 13:48:58 -0700

Ahh, the big discussion on XML begins.  

I'd like to add to Surendra's listing of some of the advantages of using
XML.  
 - XML parsers are simple.  
 - XML parsers are becoming ubiquitous -- i.e. shipping in IE
 - XML will become the preferred structured data format for many clients,
including many MS clients.
 - XML works well on light-weight devices, on which users will certainly
want to have their calendar.
 - XML can convert fairly easily to and from legacy formats.  Either the
server or the client can do the conversion, but a good server for thin
clients would do conversion to XML so that the thin client only needs one
parser.

The big thing I don't want to do is perpetuate non-XML formats by defining
new ones.  That just increases the eventual pain of switching.

Lisa

-----Original Message-----
From: Surendra Reddy [mailto:[email-masked]]
Sent: Tuesday, September 15, 1998 12:27 PM
To: Doug Royer [N6AAW]; [email-masked]
Cc: Surendra Reddy
Subject: RE: Accelerated CAP (draft-2)

I do agree 100% with Doug and it is not definitely worthwhile spending
another 6 months bashing out
requirements before we start the protocol specification.  We need to get CAP
Protocol started with some
basic requirements agreed upon. Doug's idea is excellent.  I donot see any
objections to that so far.

On a different note, I donot see any reason why CALSCH working group is not
considering XML to
represent Calendar Objects? I have gone through threads of discussions on
XML in the past and most of the
discussions took place before XML is recommended as standard. I donot think
that analysis is any longer
valid as it is being used in many criticial applications today. Open any
technical magzine you can find XML
in it!!!  WebDAV is a good example where XML is
used to define document model. I donot see any diffenence in the document
Object Model and Calendar
Object Model both are characterized by a set of property values and content.
WebDAV also provides a set
of extensions HTTP/1.1 to access and modify these object properties. There
is a good scope to reuse WebDAV efforts.
XML is being used in many working groups OTP(Open Trading Protocol -
representing ECommerce Object using XML),
Workflow Access Protocol are some good examples.

Developing  one-to-one mapping from current Calendar Object to XML DTD is
not a big deal. I had submitted a
draft ( Simple Calendar Access Protocol:
http://www.ietf.org/internet-drafts/draft-reddy-scap-00.txt) which contains
the complete DTD for the Calendar Object Model.

Even I can volunteer to build a parser which can take current Calendar
Objects syntax and translate to
a well formed XML documents.  While XML is being adopted in every business
applications and every protocol,
I donot see any reason why we should not use it in Calendaring which is part
of many collaboration applications.

Representing Calendar Object Model in XML addresses Extensibility and
Internalization very well. Security issues
are very well addressed by various consortiums like OTP, FSTC describing how
to sign XML documents.

Having said these, I would like to see how many in this group are strongly
opposing XML and if so, Can I
ask them to give 5 good reasons how current iCalendar model is better than
XML  Model or why they oppose XML?

Regards,

Surendra Reddy
(650) 506 5441

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Doug Royer [N6AAW]
> Sent: Monday, September 14, 1998 7:13 PM
> To: [email-masked]
> Subject: Accelerated CAP (draft-2)
>
>
>
> At the Chicago meeting Anik and others proposed that the CAP-REQ
> documentation should be out by the December IEFT. There was
> not much (any?) objection at that time.
>
> After the meeting I talked to several companies and feel that
> many thinkthat we need to accelerate the CAP protocol in order to
> have our products sooner and interoperate sooner than would
> be possible with the proposed schedule. So this is my WG attempt
> to accelerate the process by volunteering to carry and drive issues.
>
> Several of us at unofficial IETF Chicago meetings noted that the
> CAP-protocol is necessary, it will be time consuming to develop the
> requirements document, longer to development the CAP drafts, and will
> not be available in the short term and hinder our short term company
> goals. So this is an effort to speed up that process.
>
> I feel that the scope of CAP is at the correct level. Its just
> that I am hoping to help move a first draft of CAP out by the first
> of the year.
>
> My plan is to attempt to help drive issues to resolution. I will be
> sending out a series of emails attempting to do this. And I am
> offering to help coordinate and pull and push the items into a draft.
>
> Lets find our common grounds, thensee how we can work out
> our differences.
>
> --
>
> Here is 'my' list of the items that I think need to be discussed first.
> Soon I will be sending out some email on each of these topics below.
> I have specific proposals and will include my arguments in favor of the
> proposals.
>
> The current CAP-REQ draft covers these topics. I feel that
> when the ones below are settled, many of the others will
> fall into place.
>
> - Thinness of a minimum client and thickness of a all encompassing client.
>
> 	o How much effort would be needed for a client in order
> 	  for someone to implement CAP on the client side.
>
> 	o This effects the model for the CAP protocol.
>
> 	o Would need to includes fallbacks for disconnected thinner
> 	  clients (likePDAs).
>
> - ACLs.
> 	o We would need to define a CALSCH-ACL.
>
> 	o How a CALSCH-ACL would fit into the other ACL models
> 	  currently in rfc or draft status. Would we need to care?
>
> - administration
>
> 	o What minimum administration would be needed?
>
> 	o What optional administration should be defined?
>
> 	o How to transfer the requests/replys over the wire.
>
> - store / fetch.
>
> 	o Issues with storing/updating/fetching components and
> 	  how to submit the requests.
>
> - Synchronous Vs. Asynchronous notification.
>
> 	o One model, both?
>
> 	- Alarm information.
> 	- Change Notification.
>
> - Search / Listing calendars.
>
> 	o How elaborate should this be?
>
> One of the things that I learned in Chicago was that many
> of us wished to do the same things. We just each had our
> own way that we wanted the CAP protocol to perform the task.
>
> Many feel that ACLs are complex and may consume much time.
> After talking to several of you, I don't think it will be
> that difficult IF we can define a way that clients (perhaps
> not servers) can selectively ignore parts of the ACL it does
> not wish to implement (client simply gets permission denied).
> More in my ACL email to come out soon.
>
> -Doug
> -------------------------------------------------------------------
> [email-masked]		http://www.royer.com/dougr.html
> 801 W. El Camino #131		Work:   (650)786-7599
> Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL
>
>

---

From: "Surendra Reddy" <[email-masked]>
Date: Wed, 16 Sep 1998 18:56:39 +0100

FYI: another piece of news to show how XML is being adopted by business
solution provider.

Surendra

From PC Week
ERP Systems Tap XML for Data Sharing
September 14, 1998

PC Week : ERP vendors are embracing xml as a way to lighten system workloads
and simplify data sharing between enterprise applications.

Enterprise resource planning heavyweights PeopleSoft Inc., Oracle Corp. and
SAP AG plan to incorporate Extensible Markup Language syntax into products
to help companies lower the cost and labor involved in exchanging data with
business partners.

Separately, third-party software vendors are pushing XML to enable data
exchange over the Web between disparate financial systems from developers
such as Baan Co. and Oracle Corp.

A fundamental, standard data format has great appeal to ERP managerswho
have had to build a proprietary interface for each of their companies'
customers or partners.

"[With XML] you don't have to create as much work between you and your
business partners," said John Wick, a technology scientist for major systems
integrator Science Applications International Corp., in McLean, Va.

Wick uses webMethods Inc.'s XML-based B2B Integration Server, which is being
tailored for SAP R/3 systems. Even though users have to make data
XML-compliant, the language still is more effective than current
machine-to-machine exchange formats such as electronic data interchange,
Wick said.

"[XML] makes a lot of things possible," he said. "It could become a de facto
standard interface that simplifies a lot of the [data exchange] problems
that are now formidable."

In November, PeopleSoft will announce full XML support for the next version
of its PeopleTools software. XML will be the mechanism for data exchange
between applications created by the tools, which are used to develop and
customize applications for the PeopleSoft 7.5 suite. The new tools are due
next year, said officials of the Pleasanton, Calif., company.

Oracle plans to support XML next year in its open APIs and in Oracle
Workflow, which would use XML as one of the messaging format options for the
events generated from the tool, officials of the Redwood Shores, Calif.,
company said.

SAP, the leader in the ERP market, late last month announced plans to
exploit XML's data exchange capabilities in its products beginning early
next year, as part of its Business Framework architecture.

SAP wants to combine XML with its BAPIs (Business APIs) so its products can
use XML as a data container for workflow and other documents and as a
content format for electronic forms, said officials of the Walldorf,
Germany, company.
> Behalf Of Lisa Lippert (Dusseault) (Exchange)
> Sent: Wednesday, September 16, 1998 9:49 PM
> To: 'Surendra Reddy'; Doug Royer [N6AAW]; [email-masked]
> Cc:Surendra Reddy
> Objects syntax and translateto
> > many thinkthatwe need to accelerate the CAP protocol in order to
> > that I am hoping to help move a first draft of CAP out by thefirst
> > of the year.
> >
> > 	o Would need toincludes fallbacks for disconnected thinner
> > 	  clients (likePDAs).
> >
> > - ACLs.
> > 	  currently in rfc or draft status. Would we need tocare?
> >
> > - administration
> >

---

From: Chris Newman <[email-masked]>
Date: Thu, 17 Sep 1998 08:21:54 -0700 (PDT)

>  - XML parsers are simple.  

Trivially true because parsers are simple for almost any regular data
format.

However, XML interpretors could be extremely complex, especially if they
support things like arbitrary PITargets and automated DTD discovery.

>  - XML parsers are becoming ubiquitous -- i.e. shipping in IE

If there was an XML parsing API in every major OS, then it would be
ubiquitous.  Hype for XML may be ubiquitous, but just because it's
shipping in one Microsoft product does not mean it's ubiquitous.  In
addition, regular expressions are ubiquitous, but that doesn't mean we
should use them everywhere.

> including many MS clients.

Predicting the future.

> want to have their calendar.

Are you sure?  Is there a sample palm pilot client supporting the full
generality of XML including DTD interpretation and discovery?  And will 
the 7 or 8 ways of encoding the same character in XML work reliably?

> clients would do conversion to XML so that the thin client only needs one

Just because conversion is easy, doesn't mean it should be done.  It's
easy to convert stored Internet mail to using LF-separated lines, but it
breaks all sorts of things.

> new ones.

I'll tentatively and conditionally agree with this one.  An XML-structured
syntax is far from the worst choice one could make and in the grand scheme
of things, syntax matters little for new work.  But iCalendar is a done
deal.

> That just increases the eventual pain of switching.

Switching to XML from an existing format is more likely to be a bad thing
than a good thing, IMHO.  Parsers are simple, re-deploying code and
creating migration infrastructures is very hard.  Switching to XML might
save a few screenfuls of code if the migration ever completes, but during
the process of the migration there will need to be hundreds of pages of
transition code.  It usually won't be worth it.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Thu, 17 Sep 1998 10:12:22 -0700 (PDT)

> such as Baan Co. and Oracle Corp.

A perfect example of how trade rags totally miss the real issues.  In
fact, XML will do almost nothing to improve interoperability unless these
companies also agree to use common DTDs.

If I do an ACL like:
 <acl-entry rights=rw>joe</acl-entry>

and someone else does an ACL like:
 <acl-entry>joe<grant>read</grant><grant>write</grant></acl-entry>

Both are XML-style syntax, but there's no interoperability.

Note that I'm not opposed to reviewing an XML DTD for iCalendar in this WG
since it seems it will be developed with or without IETF cooperation, but
I am opposed to changing iCalendar protocols to permit use of that syntax
over the wire.  One wire representation of data is almost always better
than two.

		- Chris

---

From: Mark Baker <[email-masked]>
Date: Thu, 17 Sep 1998 18:36:05 +0000

> Both are XML-style syntax, but there's no interoperability.

Having a DTD is a sufficient condition for interoperability, but not a
necessary one.  But we're way off charter.

> over the wire.  One wire representation of data is almost always better

Right.  I expect ISVs to push for XML over-the-wire eventually, but it's
really not a good idea right now.  And if they don't, well that's fine
too.

MB
--
Mark Baker, CTO, Beduin Communications Corp.
Ottawa, CANADA         http://www.beduin.com