Subject: CALSCH minutes from Minneapolis

From: Bob Mahoney <[email-masked]>
Date: Thu, 22 Mar 2001 11:26:37 -0500

Calendaring and Scheduling Working Group (WG) (calsch)

WEDNESDAY, March 21 at 1530-1730
=================================

CHAIRS:	Pat Egen <[email-masked]>,  Bob Mahoney <[email-masked]>
REPORTER: Walter Houser <[email-masked]>

1. Agenda Tweaks - Bob Mahoney
         None

2. IPTEL/CALSCH issues - John Stracke

http://calsch.research.ecal.com/iptel/outline.html

The IPTEL Working Group wants to use iCAL recurrence rules (RRULES) 
in their Call Processing Language (CPL). CPL has to run in a 
telephony switch where CPU and memory are expensive. So IPTEL needs 
to pick and choose which rules apply, and has tried to severely limit 
the functionality owing to the limited flexibility and capacity of 
telephony hardware. CPL defines a subset of the iCAL recurrence rules.

The IPTEL document is currently blocked, due to questions about 
compatibility with iCalendar.  Consequently, we need to harmonize 
iCAL and CPL.  The hope is to define a common subset. Unfortunately, 
for IPTEL, iCAL rules are capable of extremely complex expression. 
Vendors could develop User interfaces (UI) that implement disjoint 
subsets which would not interoperate. John has written a draft subset 
of RFC 2445 which he will submit after this meeting.

Jonathan Lenox (Columbia Univ) from the IPTEL WG, noted that there is 
no obvious way to determine what iCAL RRULE functionality is 
reasonable and what is not. For example, IPTEL needs to have the 
duration less than the minimum unit. But there is no barrier to 
absurdity. Bob said we would take this issue to the list.

3. CAP status - Steve Mansour/George Babics

The latest draft cleans up and fixes a number of issues. However, 
there are no fundamental changes made to CAP. Remaining issues:

- CAP may be too complex to readily implement.  (Steve addressed this 
point in detail later in the meeting)
- Restriction tables are tricky and detailed; they require careful review.
- There are a number of unresolved issues in these tables.
- These tables need to be consistent with iTIPS tables.
- How do VCARs apply to a calendar hierarchy? - How should we handle 
decreed VCARs?
- We need to list and submit IANA entries. - We need to verify 
current examples and add more examples.
- We need to review the CAP requirements draft to ensure each is 
being addressed or explained away.
- We need to verify security and whether VCARs are sufficient.
- Add new properties to the restriction tables.

We need people to verify the features in the iCAL and CAP documents.

4. CALSCH.ORG web site -Bob Mahoney

The CALSCH.ORG site is up, and being sponsored at MIT. It has current 
and expired WG documents, as well as a list of vendors implementing 
calsch protocols. However, there are a number of features we could 
add; suggestions are welcome.  (see www.webdav.org as an example of 
what is intended)

5. Have we bit off more than we can chew? -Steve Mansour

Are the sheer size of the documents and scope of effort impeding 
adoption of these standards? Recent edits to the CAP draft cut the 
size down from 150 to 116 pages. (This was largely through the 
removal of the SCHEMA section to the next rev of iCalendar) 
Nevertheless, Steve recalled Tony Small (Microsoft) who was ruthless 
in fighting additional features he felt were "too complex".   And now 
Steve is concerned that Tony may have been right, and that over 
complexity is hindering adoption. We need high adoption and 
interoperability between vendors in order to succeed. The 
implementation of interoperable standards will grow the market for 
the calendaring products.

How are things going? Four vendors showed at the first Calconnect. We 
saw limited METHOD support, yet we added a lot of stuff to iTIP that 
has not been implemented such as RRULES and MIME wrappers. Are any 
vendors implementing VJOURNALS?

Why so little progress? Calendaring and scheduling is just inherently 
complicated. In contrast, mail is a static document, saved in 
publicly writable inboxes. CAP is even more complex than iTIP, and 
there is concern that  many vendors are holding back, and waiting for 
the market to develop.

What do we do? If no one implements the RFC, it's worthless. Ine 
suggestion to reduce complexity is to remove as many of the SHOULDS 
as possible, focusing on features that will maximize implementations. 
Another possibility is to eliminate fanout in CAP. Currently, it is 
in CAP as a definition, with the implication that it be implemented, 
but not fully specified. But if we push for implementation of fanout, 
we will have a lot of work to do with respect to access control, 
which will add greatly to the size and complexity of the document.

Dave Crocker commented that fighting complexity is the right thing to 
do. He felt the WG must get rid of as many SHOULDs as possible. One 
of the keystones of a successful IETF WG is to take the intersection 
of the suggested features, not the union of the requirements. If the 
feature is mandatory for most, then yes, put it in the RFC. If it is 
mandatory only for some, then no, leave it out. Furthermore, write a 
small set of scenarios to illustrate how the RFC will make life 
easier.

Bob noted that many of the SHOULDs were the result controversy 
between those who argued that it was a MUST versus those who said 
NEVER, so with review, it's possible that some SHOULDs would remain 
or change to MUSTs.

Steve observed that the authors have begun to review the SHOULDs. We 
pushed the schema out of CAP into iCAL. We wrote a pseudo-SQL 
description for the calendar store for the CAP. It is out of CAP and 
will be put into another document.

Dave asked about shifting to XML encoding. The XML tools are finally 
coming out enough to make this real possibility.

Paul Hill replied that there was a binding draft between iCAL and 
XML. Although he is leery of going to extended namespaces and 
queries, he would like some to pick this work up.  (This expired 
document will be moved to the calsch.org site)

Dave: The WG should show how the standard does valuable functions, 
like the ability to "beam" virtual business cards or add them to 
signature files. The IMPP presence protocol needs iCAL and VCARD and 
is developing this in XML. There is a lot of energy in IMPP that 
CALSCH could tap.

Steve said he would post specific proposals to the list.

6. "Guide to Internet Calendaring" Last Call -Bob/George

This is in WG last call and there was some feedback. The title is 
changed to "Guide to Internet Calendaring" and will be made an 
Informational RFC.

7. RFC updates and status

RFC 2446 and 2447 have been updated and were discussed at 49th IETF 
in San Diego. We are waiting for the results of Calconnect II before 
submitting these changes. We want to deal with any holes from the 
interoperability testing before resubmitting these RFCs.

8. Plans for further informal meetings during the week.

Those WG attendees remain after the meeting are encouraged to get 
together and continue discussing the issues raised.

CALCONNECT II April 12-13 at Stanford has five vendors plus a number 
of open source submitters.  The chairs will be making efforts to 
encourage vendors who have dropped out of the CALSCH effort to 
return, as well as relate that we may have a new appreciation for 
their objections in the past.

9. Adjourn.

---

From: Mark Tearle <[email-masked]>
Date: Fri, 23 Mar 2001 00:55:22 +0800 (WST)

> their objections in the past.
Out of curiously, which open source projects are contributing?

Yours
Mark
-- 
Mark Tearle - [email-masked]

"Friends help you move. Real friends help you move bodies." -- unknown

---

From: Bob Mahoney <[email-masked]>
Date: Thu, 22 Mar 2001 12:07:24 -0500

As I look at what I just typed, "a number of submitters" overstates 
the case a bit.  :-)

Open Source folks we know about are listed at 
http://www.calsch.org/icalsite.html#d1

We have spoken with the reefknot folks, and Eric Busboom has been 
active in conjunction with his
libical work (http://softwarestudio.org/libical/ ).  Pat of I will be 
making another run at the entire list to see who can participate.  We 
intend to have support for object testing via email for those unable 
to attend in person.

-Bob