Subject: Re: 43rd IETF Calsch Meeting Notes (plaintext)

From: David Madeo <[email-masked]>
Date: Wed, 16 Dec 1998 22:12:53 -0500

[Already had one complaint about the attachment so ...]

43rd IETF Calendaring and Scheduling WG Meeting Notes
Orlando, FL.  December 7th, 1998.

Background:
========== 
It is assumed that you are already familiar with the IETF CALSCH WG
charter and the working groups's (WG) documents.

  Charter:  http://www.imc.org/ietf-calendar/charter.html
  Web page: http://www.imc.org/ietf-calendar/ 
  Archive:  http://www.imc.org/ietf-calendar/mail-archive/
  
Opening:
=======
Bob Moskowitz (the Chair) opened the meeting and announced (as noted
in the WG mailing list) that iCalendar [RFC2445], iTIP [RFC2446], and
iMIP [RFC2447] have progressed to "Proposed Standard" RFC's.  Bob
mentioned that Anik had resigned as co-chair. Opentext will continue
to participate in the WG.  He asked if anyone was interested in
joining him as co-chair.  Frank Dawson mentioned that Pat Egen was
interested in assisting the chair.

Bob also mentioned that the WG needs to complete its existing
"chartered" work in a timely fashion. After which the WG status would
be changed to "INACTIVE" while completing the interoperability testing
of the WG's standards. New work items not covered by the existing
charter would be created in a different WG.

Locate:
======
http://www.ietf.org/internet-drafts/draft-ietf-calsch-locating-01.txt

The Locate document is in AD review, on it's way to IESG last call.

FPI:
===
http://www.ietf.org/internet-drafts/draft-ietf-calsch-icalfpi-00.txt

Frank Dawson spoke about the Formal Public Identifier (FPI) document.
FPI's (ISO 9070) are used by XML to specify a unique identifier. This
draft specifies a FPI that is associated with the iCalendar [RFC 2445]
format, allowing XML documents to refer to an iCalendar object. Bob
Moskowitz will announce a WG Last Call on this document.

Interoperability Workshop:
=========================
http://www.imc.org/imc-calconnect/

Paul Hoffman announced that the Internet Mail Consortium (IMC) would
sponsor a "CalConnect" interoperability event on Jan 19, 1998 in San
Jose. The event will be a forum for implementers to test the
interoperability of their iCalendar implementers. The event is
described fully at the above web site.  Developers with an iCalendar
product should try to attend. There is a participation fee of $1000
for IMC members and $1500 for non-members which admits three
participants. Freeware toolkit authors may have their fees waived.  No
marketing types or tourists allowed.

Products will be tested against each other.  Results will be published
on the WG and the IMC web site, including problems discovered during
testing.  It was indicated that people with products in an alpha state
will get much more benefit than one in a beta or finished state.

XML Drafts:
==========
http://search.ietf.org/internet-drafts/draft-dawson-ical-xml-dtd-00.txt
http://search.ietf.org/internet-drafts/draft-reddy-xml-ical-00.txt

There are two documents that cover XML representations of iCalendar.
Frank Dawson and Lisa Lippert met to discuss how to resolve the
differences and move this forward.  They'll post the subsequent work
to the WG.

Frank Dawson asked the group to send comments to the mailing list on
the pros/cons of the use of XML, instead of the existing "MIME
friendly" syntax in the WG's documents.

iRIP:
====
http://search.ietf.org/internet-drafts/draft-ietf-calsch-irip-02.txt

Changes to Document:
 - Updates to state diagram
 - Improved error codes and examples
 - Removal of duplicate error codes between iTIP and iRIP
 - Referrals are handled on RECIPIENT command
 - Specified server behavior if timeout occurs during ICALDATA command

Additions to Document:
 - Queued requests
 - Ability to fanout requests to other iRIP servers

Needed for last call:
 - A command table
 - Ability to ABORT during RECIPIENT command
 - Positioning of iRIP with respect to CAP
 - Complete fanout open issues (e.g.: referrals)

Roadmap:
 - Goal is to have WG last call posted within two weeks of this IETF
meeting

Discussion points:
 - "Overwrite" capabilities
 - Are the iRIP editors were looking at LDAP for the ACL portion of
   the address lookups (like with vcard)
 - Bob Morgan ([email-masked]) asked about the difference
   between uid and uuid, could we leverage existing ISO work.

CAP:
=== 
http://search.ietf.org/internet-drafts/draft-ietf-calsch-capreq-02.txt 

[These are taken from the original slides with comments added to the
end under discussion points]

Document Editors:                Other Contributors:
----------------                 ------------------
 - Andre Courtemanche            - Surrendra Reddy 
 - Frank Dawson                  - Doug Royer
 - Steve Mansour                 - Richard Shusterman 
 - Pete O'Leary                  - Lisa Lippert
 - Tony Small

Status of Interim Editor's Work:
-------------------------------
 Actions From Last Meeting
 - CAP Requirements Document Editors charged with revising/completing
   draft
 - Submit to WG mailing list by Dec'98 IETF
 - Initiate WG last-call by Dec'98 IETF

 Positioning of WG Standards
 - iCalendar
   The "core object" specification
   Provides "nouns" for defining calendar info
 - iTIP, iMIP and iRIP
   The interoperability protocol
   Provides "verbs" for defining interoperability
 - CAP
   The calendar store access protocol
   Provides "verbs" and new "nouns" for CUA-CS calendar interaction

Goals of CAP:
------------
 - Standard protocol for CUA-CS interaction
 - Allow a mix-and-match of different CUAs and CSs
 - Permit single CUA to access multiple CSs
 - Provide sufficient functionality for "full-featured" CUA
 - Enable development of "calendar-enabled" applications
 - Support for "small footprint" CUA without a local store
 - Enable CUA configurations that synch with remote CS
 - Useful in environments characterized by low-frequency connection
   and low-bandwidth transports
 - Allow leverage of high-bandwidth transports
 - Provide a basic support for calendar access and security

NOT Goals of CAP:
----------------
 - Not a client-to-client protocol
 - Not a server-to-server protocol
 - Others in specific categories (see draft)

CAP Requirements:
----------------
Connection Scenarios
 - CUA with single remote CS
 - CUA with multiple remote CS
 - CUA with single local CS, single remote CS
 - CUA with single local CS, multiple remote CS
 - CUA with multiple local CS, multiple remote CS

Component Management
 - Create components, on a given calendar
 - Delete components
 - Retrieve specific components and properties
 - Modify whole properties and components
 
 All operations subject to access control

Search and Lookup
 - Search for components based on attributes
   WebDASL has been proposed for these semantics
 - Lookup/discovery of the calendars on a CS
 - Lookup/discovery of properties on a calendar
 - Lookup/discovery of parameters on a property

 All operations subject to access control

Proposed Data Model:
-------------------
 http://www.imc.org/ietf-calendar/db.gif

Proposal for Addressing Calendars in CAP:
------------------------------------

 - A "Qualified CSID" conforming to the "Common Internet Scheme" of
   RFC 1738

     <protocol>://<host.domain>/<calid>
     <calid> := <any 7bit US-ASCII identifier>

 - For example:
   CAP://server.calendar.com/bond007

Deferred Requirements:
---------------------
 Why defer anything?
 -  Timely definition of an initial draft
   » 1999 draft through WG review
 -  Dependencies on other IETF work
   » e.g., Notification
 -  Larger scope unmanageable
    Otherwise it's just too frickin hard!!!

Deferred Requirements:
---------------------
 - Copy a calendar from/to a CS
 - Undelete previous calendar operation(s)
 - Scripting of CS-based agents
   Rules running on the CS
 - Notifications
   CUA notified by CS about calendar "activities"
 - Grammar definition of calendar access rights
   "Calendar access policy" support non-deferred
 - Advanced resource scheduling requirements
 - Convert inline binary to external object and provide a URI to
   external object
 - "Rollup" sub-calendars into one logical calendar
 - Transaction locking of a calendar
 - Group operations on a set of calendars 
   No CS "fan-out" of scheduling requests
   NOTE: Can be done using iTIP bindings
   NOTE: Can be done by CUA using multiple CAP sessions
 - Automatic synchronization between calendars

Proposed Schedule of Work For 1999:
----------------------------------
 - Two interim WG meetings
   Opportunity for "core design team" to progress CAP component
   proposals for mailing list review

     Feb 9-10, New York City
     Mar 9-10, Menlo Park

   >> Open to all IETF'ers who want to contribute
 - Deliver WG proposals for CAP components:
   Data model, system model, various proposals for CAP subcomponents
 - Next IETF meeting and beyond
   Additional direction for "core design team"
   CAP v1 specification

Proposed Work Items
And Discussion-Lead-Contacts:
----------------------------

 - CAP models (data and system) - Steve Mansour
 - Calendar addressing - Steve Mansour
 - Calendar properties - Richard Shusterman
 - Calendar store properties - Richard Shusterman
 - Searching and filtering - Lisa Lippert
 - Component management - Doug Royer
 - Access right, security - Andre Courtemanche
 - Protocol syntax (XML versus MIME) - Tony Small
 - Transport (HTTP versus TCP) - Doug Royer
 - Exception Handling - Doug Royer
 - Session management - Richard Shusterman
 
Deferred Work Items
And Discussion-Lead-Contacts:
----------------------------

 - Calendar access rights - Frank Dawson
 - Resource groups and pools - Pete O'Leary
 - Notification - TBD

Discussion Points:
-----------------
 - The language of "MUST" versus "SHOULD" needs to be carefully
   considered, to enable a small footprint clients.  i.e.: Don't
   require LDAP to do CAP. Others asked if we still needed a "small
   footprint" section since so many limitations have gone away. The
   Chair noted that "small" keeps changing (cell phones now) and that
   we should keep it.
 - Locking and WebDAV
   (http://www.ietf.org/html.charters/webdav-charter.html).  Jim
   Whitehead ([email-masked]) suggests that locking should be a
   required part of CAP, but what type of locking?  Perhaps WebDAV has
   set some precedents the WG could leverage.
 - Define local versus remote server. Matt Wall ([email-masked])
   asked "does the local and the remote server have to be the same
   implementation?"  Also, need to be careful with disconnected
   mode. IMAP in particular took a long time to get this right.
   Again, perhaps we could leverage their work.
 - Search is important.  Web DASL has pro's and con's and has been
   suggested as one possible way to implement this against calendars.
 - Lookup is different than searching.  Lookup finds values while
   searching finds specifics.
 - Data model (see url above) was drafted as a convenient way for all
   the CAP editors to be on the same page.
 - Addressing Calendars. There's no implicit structure to a calendar
   name.  It's currently opaque text, which some would like to change
   to be a hierarchical text.  It hasn't been completely flushed out
   though.  (e.g.: There is a difference between a user name and an
   ID.)  The Chair advised that it wasn't a problem to have an interim
   solution and then expand on it later. If there are concerns, post
   them to the WG.
 - HTTP as transport. Other WGs are having problems when trying to
   build their implementations on top of http.  The Chair indicated
   that using http would be a problem.  It was suggested that we not
   limit the transport to http. On the other hand, leveraging things
   that work (e.g., MIME) is better than a designing a new protocol.

   [My notes on this are cryptic, but I believe people were confusing
    the http protocol with the use of port 80 (default http port) in
    their discussions.  There is a difference. -dmadeo]

 - Deferred topics.  The idea of deferring hard problems is getting
   old. What about ACL discovery and ACI?
 - The Chair confirmed that interim editor meetings are ok, as long as
   they are open to interested IETF'ers and meeting notes are
   published to the WG.
 - Frank Dawson mentioned two points
   -Need to pick a transport layer
   -iCalendar RFC's published, but now XML is all the rage.  If you
    were a vendor and now CAP is being defined in terms of XML, would
    you feel the rug has been pulled out from under you (because you
    were coding to the current iCalendar "MIME friendly" syntax). Since
    RFC's use MIME syntax, is it bad to make CAP use XML?
 - Matt Wall: This is a re-inventing the wheel paradox.  His opinion
   on HTTP and XML: "don't do it". It will possibly delay the
   acceptance of the current proposals.  Wait for "version 2" of the
   RFC's for it, if still required.

CAP Plan
----------
 - Minneapolis      Mar 1999 (WG last call CAP Requirements)
 - Oslo, Norway     Jul 1999 (Initial CAP draft)
 - Washington, DC.  Nov 1999 (CAP last call?)
 - Adelaide, Aust.  Mar 2000 

The Chair mentioned that the work done on the CAP requirements is not
wasted work.  The CAP requirements will become an index to the full
protocol specification.

Closing:
======= 
- The IESG suggests that now is the time for user
level white papers on calendaring and scheduling.

- Andre mentioned that PC week had a story about calendaring that
mentioned the current documents.
http://www.zdnet.com/pcweek/stories/news/0,4153,375418,00.html

[I'd like to thank Pat Egen ([email-masked]) and Keith Rhodes
([email-masked]) for the generous use of their notes and Frank
Dawson for his comments and corrections. Please forward any
corrections or additions directly to the WG mailing list.  
     - David Madeo [email-masked]]