Subject: Re: CAP Searching Proposal

From: Doug Royer <[email-masked]>
Date: Wed, 3 Mar 1999 13:39:29 -0800 (PST)

> Date: Fri, 26 Feb 1999 03:07:29 +0000
> From: John Stracke <[email-masked]>
> 
> Frank Dawson wrote:
> 
> > Doug Royer and I have been working since the last IETF meeting on a proposal
> > for a "search" mechanism for CAP. Our approach was to build on the existing
> > market acceptance of SQL functionality and map this to the existing
> > iCalendar syntax.
> 
> It just occurred to me that an alternative would be to define a mapping
> of the calendar information into the namespace of a Web server, and then
> search it with DASL (an HTTP-based protocol being developed for searching
> the contents of a server).  The mapping would have the nice side effect
> that any calendar entry would be available to downlevel browsers via GET,
> which makes for a convenient migration path for implementors--just write
> a plugin/helper app that understands iCal, and you can get events into
> your calendar.  It's not particularly full-featured, but it's a useful
> start.

The problem with the DASL proposal is that its ~almost~ SQL. And I think
that is an issue. I talked to Alex Hoppman about this in Orlando;
he told me the reason that its NOT SQL, is because they needed some
features that were not in SQL. I still don't see why they can't say
is SQL (version xxx) + plus this or - that's our plan.

It looks to *me* as if the XML vs iCalendar debase seems to be over. CAP
is going to be iCalendar objects as a MUST with the iCalendar object
rendered as XML as an optional capability. With the details of the XML
extension as a separate draft/rfc.

Have you seen ietf-many-ical-xmldoc-00.txt ?  I do feel that there
needs to be an XML story. I also strongly feel that CAP MUST
have iCalendar objects by default.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Wed, 3 Mar 1999 14:58:03 -0800 (PST)

> From: "Tony Small (Exchange)" <[email-masked]>
> Date: Wed, 3 Mar 1999 14:42:34 -0800 
> 
> Doug,
> 
> It's not really clear from your description below what your issue is with
> John's suggestion.  Is it a symmantec thing?  "almost" vs. "sql + xyz"?

If DASL were to say "its SQL + something or - something" that would
be okay with me. It in effect says here is the query language, and it
just happens to look like SQL. Lots of expert took a lot of time working
out SQL and the text to describe it. (ANSI Standard x3.135 I think).
I think it would be wise to take advantage of those experts.

For the DASL topic; This is not the DASL WG, so if you want to continue,
we can move this to the appropriate WG alias.

For CAP; Don't you think we should use existing standards and not
invent our own?  I think you were the first one one to ask me that :-)

-Doug

---

From: "Tony Small (Exchange)" <[email-masked]>
Date: Wed, 3 Mar 1999 14:42:34 -0800

Doug,

Also, you said in an earlier posting regarding your concern with MUSTing
XML:

"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.
Several of us think that we REALLY NEED a CAP, and soon."

I'm concerned with moving forward with a decision for the purpose of saving
a working group.  A working group should function to create a standard that
serves customer and vendor needs.  A standard should NOT be created (or
rushed forward) to save a working group.

If there is significant interest with moving towards XML after "CAP 1", I
see it as long term detrimental to rush forward drafts that are not XML.
It's unrealistic to expect all vendors in several years to support both
formats.  I think we need to take a hard look at what we do now both in the
long term regarding what's best for customers, vendors, and for future
interopability.  These goals should supercede any efforts to save a working
group.

Finally, I do agree with Phil that we are early in the race, and
representing the only product that is about to release an iCal/iMip standard
compliant program, I can say that.  We wanted to have an interop event in
January, but only one other company was even close to ready - and I recently
found our they're not even planning to support recurrences.  Let's not
pretend there are tons of products rushing through the door that will
support iCal when that's simply not true.

Tony Small
Microsoft Outlook

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Wednesday, March 03, 1999 1:39 PM
To: [email-masked]
Subject: Re: CAP Searching Proposal

-Doug

---

From: "Frank Dawson" <[email-masked]>
Date: Wed, 3 Mar 1999 22:58:22 -0500

Tony:

I don't think that the focus on CAP is an effort to save the WG. The working
group has done a great series of specifications. Our focus is now on
completing the last of our chartered items.

The emphasis on CAP comes from a strong interest in both the end-user and
vendor community.

See you at next weeks CAP design meeting.

-- Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Wed, 3 Mar 1999 22:49:31 -0500

>John Stracke wrote:
>
>It just occurred to me that an alternative would be to define a mapping of
the
>calendar information into the namespace of a Web server, and then search it
>with DASL (an HTTP-based protocol being developed for searching the
contents of
>a server).  The mapping would have the nice side effect that any calendar
entry
>would be available to downlevel browsers via GET, which makes for a
convenient
>migration path for implementors--just write a plugin/helper app that
>understands iCal, and you can get events into your calendar.  It's not
>particularly full-featured, but it's a useful start.
>

Won't scale. The XML representation of an iCalendar object is great for an
on the wire format but is not a practical representation for the backend.
For DASL, you would be searching through documents. If you took this
approach, then each parameter in an iCalendar property might have to be a
separate document (taken to extremes, but I hope you see the problem).

- - Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Fri, 12 Mar 1999 15:34:27 -0500

Lisa:

Sorry for the delay in responding.

Yes, thanks to John (and you) for setting me straight about property _and_
parameter capabilities of DASL. Definitely, an error on my part.

If we were to use XML as the standard format for CAP, DASL would seem to be
candidate for the search semantics. However, there is also the use of the
XQL draft. In fact, SQL seems a better bet because of the ubiquitous nature
of SQL semantics to programmers.

However, I must say that it seems that the consensus is emerging for
sticking with the current standard RFC 2445 syntax for CAP.

- - Frank