Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/calsch/calsch-minutes-97apr.txt

Text File | 1997-05-29 | 12KB | 272 lines

Editor's Note:  These minutes have not been edited.


Minutes for the Calendaring and Scheduling (CalSch) Working Group
38th Internet Engineering Task Force
Memphis, Tennessee
April 8, 1997
1:00pm CDT

Reported by: Ross Hopson ([e-mail])

Co-chair, Anik Ganguly opened the meeting and began with a review of
the agenda:

a1) Agenda Review

a2) CalSch status report

a3) Discussion of iCalendar Core Object Specification Draft
<draft-ietf-calsch-ical-01.txt>, with the goal of issuing a last call
after the next edit.

a4) Discussion of protocol requirements
<draft-ietf-calsch-rtreq-00.txt> and solution approaches using TCP
vs. HTTP vs. SMXP, with the goal of selecting a transport and
producing a draft.

The origin of the CalSch WG was reviewed: the WG began with a lunch
meeting at the 36th IETF conference, the charter was approved on
October 29, 1996, and the WG first met at the 37th IETF conference.

The CalSch status report was begun by reviewing the original
schedule.  The WG was behind schedule for submitting iCalendar to the
IESG, so a "straw man" revised CalSch schedule was proposed:

May 1997 - Submit the iCalendar Internet-Draft to IESG for
consideration as a proposed standard.  The WG accepted this.

May 1997 - Agree on interoperability requirements.  The WG accepted
this.

June 1997 - Submit Draft 1 for: b1) Transport Independent
Interoperability protocol Internet-Draft; b2) Real-time binding for
Interoperability protocol I-D; b3) E-mail binding for
Interoperability protocol I-D.  The WG accepted this.  However, a
question was raised concerning whether there might be too many CalSch
drafts, and whether some of them might be combined.  It was agreed
that a clarification of the drafts was needed.

July 1997 - Submit Draft 2 for: b1), b2) and b3) above.  The WG
accepted this.

August 1997 - Submit to IESG for consideration as a proposed standard
for: b1), b2) and b3) above.  The WG accepted this.  It was asked
if it would be necessary to have a demonstration of interoperability
before submitting the draft; it was decided that this was not
required.

December 1997 - Submit Draft 1 for: Access Protocol I-D.  There was
discussion and general agreement that work on the access protocol
draft should wait until other drafts (such as iCalendar) have been
completed, and that there was no need for further discussion of
access protocol until there was more WG agreement on supporting
issues.  It was stated that an access protocol draft has been
written, (draft-oleary-icap-01.txt> but it was agreed that discussion of
the draft should wait for acceptance of the iCalendar draft.  It was
asked whether there was a need for an access requirements document,
and it was determined that this would be necessary.

Next the CalSch products (documents) were reviewed:

iCalendar - <draft-ietf-calsch-ical-01.txt> - This document defines
the system model that is used to define the CalSch protocol suite. As
such, it defines the abstract communicating entities, their roles and
their potential communication capabilities (e.g. intermittently
connected vs. constantly connected).  With the entities clearly named
and defined, this model will go on to explain the intended
application of each protocol that is defined by CalSch.  Further,
this document defines a framework for constructing objects that will
be used in the CalSch protocol suite.  It defines the object model,
the object representation and encoding rules, the data types that are
used in the objects, and it contains an exhaustive list of
attributes.  This document also defines the administrative procedure
for creating conforming objects.

InteropProtocol - <draft-ietf-calsch-cip-00.txt> - This document
defines the transport independent protocol that can be used by
communicating entities to accomplish calendaring and scheduling tasks
with another entity.

InteropProtocol Real-time Binding - This document defines how the
InteropProtocol will work over a real-time connection.

InteropProtocol E-mail Binding - This document defines how the
InteropProtocol will work over E-mail.

AccessProtocol - This document defines the protocol that can be used
between a client with calendaring and group scheduling capabilities
to talk to a server that offers those capabilities.

Discussion of the iCalendar draft began with the introduction of
Derik Stenerson and Frank Dawson (co-authors of the draft).
An overview of the current status of the draft was presented:

c1) The current draft is <draft-ietf-calsch-ical-01.txt>; the goal is
to submit the draft as a standards track in May, 1997.

c2) The following change requests were identified:  add a system
model description, add an object model description, corrections to
BNF, editorial changes, and addition of clarification text.

c3) The last call revised document to be ready by May, 1997 time
frame.

Derik and Frank asked the WG for new issues concerning iCalendar, and
made a list of these:

d1) The recurrence rule grammar should be changed back to the
original format (type: grammar).

d2) Use of the property parameter should be minimized (type:
grammar).

d3) Classify the properties into a core subset of properties and the
more complete set (type: model/conformance).

d4) The use of the terms "Value Type" and "Type" as parameters of a
property value are confusing; change the names of the property
parameter (type: editorial).

d5) The registration process is complex; remove it and require any
new profile to be defined as a standards track document (type:
process).

d6) There is a need for a clear description of the model used by
iCalendar (type: model).  Resolution:  The WG agreed that this will
either be a separate document (general consensus) or added as an
introduction to the iCalendar document.

d7) Change BNF to an acceptable form, such as a single specification,
rather than the iterative form in the current document (type:
grammar/editorial).

d8) Insure conformance to MIME (type: process).

d9) Extensions are needed to handle resource scheduling specifics
(e.g. video-conferencing) (type: model).

d10) Local time usage needs to be clarified to avoid potential
interoperability issues (type: editorial/model).

d11) Non-significant LWSP-Characters should be restricted everywhere
(type: grammar).

d12) The need for PROFILE-VERSION is questioned (type: grammar).

d13) The DUE property value should be limited to DATE-TIME, and not
allow DURATION (type: grammar/model).

d14) UID uniqueness needs to be strengthened by providing hints (e.g.
add "@domain").

Due to time constraints, it was suggested that the list be discussed
in order of priority; the two highest priority items were determined
by the WG to be d6) and d3).

The issue of the need to define the calendaring model before
discussion could continue about iCalendar was raised, and a sketch of
the system model was requested, which was begun to be drawn on a
slide. It was suggested that the model be developed after the meeting
in a small group rather than on the overhead with 50 onlookers. The
question was asked whether separate model documents would be required
for calendar objects and their transmission.  It was stated that
there should be separate documents for the system and object models.
The need for separate model documents was discussed.  The need was
defined by saying that there had not been enough interest in an
architectural document when the WG was formed, so one was never
written.  It was suggested that, since the WG members were already
together at the conference, they convene outside the WG meeting to
draft a document by the end of the conference.  The problems of
producing such a draft were discussed.  It was said that it would be
very difficult to produce an architectural document due to the
diversity of calendaring products currently available, and that there
is no one "correct" way to do group scheduling.  This thought was
continued by asking for an abstract  document (rather than an
architectural document) that would describe one true set of
"over-the-wire" descriptions or protocols in abstract form.  There
was consensus among the WG for this action.

Time had expired for this part of the meeting, so a discussion of the
other issues were left for email.  Derik agreed to put together a new
iCalendar issues list.

The meeting continued with the introduction of Steve Hanna, who began
the discussion of real-time protocol requirements for interoperability
<draft-ietf-calsch-rtreq-00.txt>.  Each of the requirements (as defined in

the rtreq draft) were described and displayed on a slide
which showed the real-time requirements and the strengths and
weaknesses of each protocol (HTTP <draft-ietf-calsch-cih-00.txt>, TCP
<draft-ietf-calsch-cip-00.txt>, and SMXP) as they pertain to these
requirements:

Real-time Requirement   | CIH   |  CIP  | SMXP
------------------------|-------|-------|-------
Bounded Latency         | Fix   | Fix   | Fix
------------------------|-------|-------|-------
Simple                  | Weak  | Strong| Strong
------------------------|-------|-------|-------
Existing Technology     | Strong| OK    | OK
------------------------|-------|-------|-------
Efficient               | Weak  | Strong| Fix
------------------------|-------|-------|-------
Scaleable               | OK    | OK    | Fix
------------------------|-------|-------|-------
Secure                  | OK    | Fix   | Fix
------------------------|-------|-------|-------
Address Resolution      | OK    | OK    | Fix
------------------------|-------|-------|-------
Deploy and Administer   | Weak  | Weak  | Weak
------------------------|-------|-------|-------

A discussion was held of what would be required to modify CIP and
SMXP so that they would meet all the real-time requirements.  It was
agreed that SASL would fix the security problem.  There was concern
over deployment, as several attendees stated that firewalls might be
a problem, explaining that it is often difficult to convince
administrators to open firewalls for new applications.  Concern was
expressed over modifying SMXP to meet all the requirements.
It was felt that this would remove one of SMXP's greatest assets, which
is its simplicity.

Discussion was held concerning CIH, and whether interoperability
could be done using existing HTTP.  While it was agreed
that the infrastructure for HTTP already exists, there was a list of
several questions for the WG:

How would port numbers be handled?  It was determined that it
is fairly easy to get a port number assigned by the IANA.

How would URL's be resolved?  It was explained that this could
be done using LDAP or URN's (Universal Resource Names).

Would the HTTP POST command be sufficient?  It was indicated that any
server can handle POST commands.

Would caching and proxying pose problems?  It was explained
that with the HTTP v1.1 implementation, caching can be
configured on a 'by request' basis.  There was concern over whether
this would work with v1.0 HTTP.

How would bounded latency be handled?  It was determined that this
problem was also covered by the v1.1 HTTP specification.

There was not a group consensus concerning which protocol would be
best.  Time was running out, so it was asked whether it was possible
for the WG to agree on the real-time protocol requirements.  It was
also asked whether bounded latency would be a problem. There was
consensus among the WG that bounded latency might not be necessary as
it is not a requirement in any other protocol.  There was consensus
among the WG to accept the real-time requirements without bounded
latency, and the discussion of and consensus over a single real-time
protocol would be continued on the mailing list.

Anik adjourned the meeting at 3:05 pm.
Anik Ganguly
OnTime
Campbell Services Inc.

http://www.ontime.com