Subject: Accelerated CAP (draft-2)

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Mon, 14 Sep 1998 11:13:04 -0700 (PDT)

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 think that 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, then see 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 (like PDAs).

- 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: "Pete O'Leary" <[email-masked]>
Date: Mon, 14 Sep 1998 15:03:59 -0700

Doug,

I applaud your effort. I've been wondering for a long time when the WG would
get serious about CAP.

While you're at it, please send me your comments on my latest ICAP draft. I
believe it encompasses a great deal of the CAP requirements in its current
state. I intend to add ACL's to the next draft, which should be completed by
the next IETF meeting.

Also, there are ICAP client and server implementations available today from
Amplitude for WG members to experiment with.

Pete.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Doug Royer [N6AAW]
> Sent: Monday, September 14, 1998 11:13 AM
> To: [email-masked]
> Subject: Accelerated CAP (draft-2)
>
>
>

---

From: "Surendra Reddy" <[email-masked]>
Date: Tue, 15 Sep 1998 20:27:09 +0100

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

> Sent: Monday, September 14, 1998 7:13 PM
> many thinkthat we need to accelerate the CAP protocol in order to
> Lets find our common grounds, thensee how we can work out
> our differences.
>
> --
>
> 	  clients (likePDAs).

---

From: "Surendra Reddy" <[email-masked]>
Date: Tue, 15 Sep 1998 20:35:47 +0100

There is also another draft developed around the requirements outlines in
CAPREQ using XML to represent Calendar
Objects and WebDAV(Http/1.1 extensions) to deliver Calendar Objects to
Clients. You can see this  draft (Simple
Calendar Access Protocol) at
http://www.ietf.org/internet-drafts/draft-reddy-scap-00.txt.

I am working on the second draft of this document. This protocol is built on
WebDAV extensions to HTTP/1.1 PROPFIND
and PROPPATCH. Using these extensions, we can easily develop CAP protocol
reusing the WevDAV effort. Also, I donot
see any convincing reasons for not using webDAV for Calendar extensions.

Any good reasons why we cannot use WebDAV extensions to implement Calendar
Access Protocol?

regards,
Surendra

> Behalf Of Pete O'Leary
> Sent: Monday, September 14, 1998 11:04 PM
> To: Doug Royer [N6AAW]; [email-masked]
> Subject: RE: Accelerated CAP (draft-2)
>
>
> Doug,
>
> > offering to help coordinate and pull and pushthe items into a draft.
> >
> > Soon I will be sending out some email on each ofthese topics below.
> > 	o This effects the model for theCAP protocol.
> >
> > - store/ fetch.
> > - Search/ Listing calendars.
> >

---

From: Mark Baker <[email-masked]>
Date: Wed, 16 Sep 1998 09:42:34 -0400

>XML  Model or why they oppose XML?

I'm for XML, as I'm sure most of you will recall 8-).  *But*, I'd prefer
not to see it replace iCalendar quite yet.  There's a legacy to concern
ourselves with, in code that supports iCalendar, vCalendar, and vCard (I,
for one, have a single parser for vCard and iCalendar).

I'd suggest we submit either your DTD, or something equivalent (Lisa?) as a
new draft spec, and mention explicitly that this is an *optional* format
that vendors can choose to support or not.  Then, wait and see what happens
...

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

---

From: "Ron Wolf" <[email-masked]>
Date: Wed, 16 Sep 1998 09:54:07 -0700

In our applications we look at the services provided by calendars and
related servers as a platform layer to build upon. As products that
support/conform to iCal come out our goals become more achievable and our
applications become portable. MaAP.

Many of our applications are browser based. A XML based interface to iCal
services is a much better interface for us than the request/response
protocols that the group has been working on. While we are likely to get
around to implementing over the request/response protocols at some point, we
are using our own dialect of XML now. Others are also using XML dialects for
calendar info exchange. The cow is already out of the barn.

It seems that a working sub-group can be mustered to move this forward. It
would be far better for the DTD to be defined here before it happens
somewhere else.
+---------------------------------+
| Ron Wolf         Squirrel Works |
+---------------------------------+

> Behalf Of Mark Baker
> Sent: Wednesday, September 16, 1998 6:43 AM
> To: Surendra Reddy; Doug Royer [N6AAW]; [email-masked]
> Cc: Surendra Reddy
> Subject: XML again
>
>

---

From: Chris Newman <[email-masked]>
Date: Wed, 16 Sep 1998 10:50:09 -0700 (PDT)

On Tue, 15 Sep 1998, Surendra Reddy wrote:
> considering XML to represent Calendar Objects?

The existing syntax is already documented and implemented.  The more
variant representations of the same data that exist, the less likely one
is to achieve interoperability.  Take email, for example.  There's the
on-the-wire format and the Unix mailbox format for email which are
incompatible due to the line terminator.  This trivial incompatibility is
probably the primary reason transport and storage of unencoded binary
objects can't be deployed in email.

However, if it is true that people will send around XML-based iCalendar
objects with or without IETF guidance, then that would be a legitimate
reason to develop an XML mapping for iCalendar objects in the WG.  One XML
grammar for iCalendar is better than many XML grammars for iCalendar.

> in it!!!

I consider hype in "technical" magazines to be a strike against XML. 
Computer magazines tend to hype things which have PR departments rather
than things which are legitimately useful because they interoperate well
in practice (the latter is usually boring).  To my knowledge, I have never
used any product or program with XML support and I've certainly never
created or transferred an XML document.

XML isn't a bad syntax -- it's certainly much better than ASN.1.  But it's
far from proven in the real world.  I suspect building interoperable
systems using fully-general XML will be very hard.  The W3C doesn't have a
good record at producing standards which result in interoperable products. 
I honestly don't trust XML yet.

>  WebDAV is a good example where XML is

One key consideration before mapping a new object into a generic object
model such as those provided by LDAP, ACAP and WebDAV is to consider the
common-case access patterns and ask the question: do the access patterns
fit well?

My gut instinct says that the common-case operations on Calendar objects
won't fit well in any generic object model.  Here are some example common
operations which will be troublesome using one of the generic object model
protocols:

	Fetch events which are meeting in the next week, in order of
         occurance
	List free time on day X
	List summary of events meeting this month
        List meetings in the next week which person foo will attend

The access patterns of calendar objects are tightly bound to the
recurrence rules and the mapping between events and free/busy time.  In
order to make the search operations in any of the generic object model
protocols work it would require a large number of "virtual attributes"
with strange behaviors.  I suspect the complexity of such "virtual
attributes" would far outweigh the complexity of a new protocol (assuming
it is similar to an existing protocol).

		- Chris

---

From: "Surendra Reddy" <[email-masked]>
Date: Wed, 16 Sep 1998 23:34:24 +0100

> From: Chris Newman [mailto:[email-masked]]
>>

Chris, I donot agree with you. Please look at the Open Application
Specification( 
http://www.openapplicaitions.org)   which provides a real life use of  XML in  'Business Object 
Document Model'  used for  Applications interoperability. You can also look at Open Trading 
Protocol(which will be available soon in IETF repositorys, this specification have been produced 
by consortium of  companies and now it is under IETF see http://www.ietf.org/html.charters/trade-charter.html). 
Royal Bank of Canada has implemented OTP spec for real life applications in Ecommerce. There are 
numerous applications of  XML in real life  than PR hype about XML. May be you are right "politically" and 
I donot  agree with your  argument on "building interoperable systems using fully-general XML will be 
very hard". It is not a rocket science. You can also look at DASL
( http://www.ietf.org/internet-drafts/draft-reddy-dasl-protocol-02.txt) effort to see
how XML is being explored to repsent query syntax for XML DTDs/DATA. 

Instead of wasting our valuable time on debating whether it is good or bad or throwing away the 
good stuff perceiving that it is bad,  it is worthwhile  and useful to the technical community if we can 
come up with a detailed analysis why it is bad or good. 

So, continuing further on my argument on using XML in CALSCH, if anybody have any negative opinions on
XML and its real life applicability in applications, please post to this list a  detailed technical analysis to 
justify your argument -- political reasons are not acceptable. 

Regards,

Surendra

---

From: "Ron Wolf" <[email-masked]>
Date: Thu, 17 Sep 1998 09:37:36 -0700

First I suggest that the "to XML or not" discussion move off of the
"accelerated CAP" thread. Continuing the discussion on that thread only
increases the concern that work on an XML iCal dialect would interfer with
iCal work that is much further along. The dilution of effort is a legit
concern, but needs to be taken in perspective.

One of these perspectives requires an understanding of what XML is and is
not. XML isn't a protocol, it is a a self describing structured data format.
I see iCal as providing value on two levels

1) defining a "vCal+" structured data format and
2) defining a protocol in which the data format is embedded.

All I am suggesting is that the group endorse the effort to create a DTD
that describes a very iCal like data format. This is the part that would be
most useful to us, now. This is the part that threatens to grow wildly as
lots of developers (like us) just do this ourselves.

Seems safe to me to then discuss how the XML format would fit into the
protocol at a later time.
+---------------------------------+
| Ron Wolf         Squirrel Works |
+---------------------------------+

---

From: "Surendra Reddy" <[email-masked]>
Date: Thu, 17 Sep 1998 11:55:29 +0100

From the various notes on XML use in iCal, there seems to be a general
consensus on reviewing XML DTD within this working group. Please post
to this list if anybody has any objections on this.

--Surendra

---

From: Pat Egen <[email-masked]>
Date: Thu, 17 Sep 1998 16:58:26 -0400

Speaking as a customer (and a representative of lots of customers) who've
been waiting on standards for longer than we choose to mention, I vote no
if it holds up progress.

---

From: Bob Mahoney <[email-masked]>
Date: Thu, 17 Sep 1998 19:02:39 -0400

>to this list if anybody has any objections on this.

Objection.  I think we have other work that takes precedence.  I seem to
remember a bunch of Neat Ideas that we deferred to subsequent versions of
our specs.  Maybe this belongs on that list.

-Bob

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 17 Sep 1998 19:31:22 -0400

If there is going to be a draft on an XML DTD for Calender data, I would
hope that it would be worked on in this group. I would not want to see it
come out of a different group, or move forward as an individual submission.

Having said that I also believe that this list is the appropriate place to
discuss the work. (After all, we all know how to filter mail, right?)

However, given our previous committments and stated directions, I would
object to this work be given time on the agenda at the next IETF meeting.
And I would object to trying to move it to working group last call before
it had ever made it onto the agenda.

Paul

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 Sep 1998 16:57:09 -0700 (PDT)

> to this list if anybody has any objections on this.

I have no objection to review and possibly even publication of an XML DTD for
Ical data, provided that:

(1) It waits until the other work this group is doing is done.
(2) It is clear that it isn't presently intended for use on the wire.
(3) The specification, if one emerges is information/experimental rather than
    standards track.

I object to anything that doesn't meet these conditions. Experience has
shown that even the appearance of competition between two different
approaches to  a problem has the potential for paralyzing an IETF WG
for months or years, and in some cases can result in necessary output
from the WG not getting done at all.

				Ned