Subject: 42nd IETF CalSch minutes

From: "John W. Noerenberg" <[email-masked]>
Date: Thu, 24 Sep 1998 12:20:32 -0700

CalSch meeting at 42nd IETF - Chicago

We began with the usual agenda bashing:

IESG status on drafts
Locating Draft status
IRIP status
CAP requirements
Next Steps

IESG status on drafts

ICalendar, iTIP, and iMIP have gone through IETF last call and have been 
offered by our Area Directors (AD) to the IESG for approval as Proposed 
Standards.  The ADs noted a few comments about the drafts, but they have 
been passed, and will be in the hands of the RFC Editor soon.  It may be 
possible the Editor will request minor changes before they are assigned RFC 
numbers.  However, these three are nearly ready to be published!

Locating Draft

Working Group Last Call completed with no major objections.  It was noted 
the draft contained incorrect references to documents.  The editor said 
he'll remove these.  After that, the draft will be ready for review by the 
ADs.  To expedite the review, they will post the document for IETF Last 
Call while they review it, instead of completing their review first.

Patrik Falstrom reviewed the steps from Working Group draft to Proposed 
Standard, and listed the times the document may need to be edited during 
this process.

iRIP status

The iRIP team reviewed their work and their plans.  They've released a 
couple of drafts which have garnered numerous comments.  They divided the 
work to be accomplished in two parts, clarifications, and open issues. 
Clarifications are changes which are not controversial and will be 
accomplished in the next draft.  Open issues are problems for which the WG 
has not found consensus.

Clarifications to be incorporated are:

o Changes to the state diagram
o Adding a command table
o Discussion of server behavior if timeout occurs during ICALDATA command
o Better error definitions and examples
o Adding referral syntax and examples
o Specify UTF8 as default charset.  Other charsets are allowed as given by MIME

We then began a discussion of the open iRIP issues.

There is a choice to be made regarding the server's behavior on a referral. 
The server can simply return the referral address, or it could both return 
the address, and attempt to perform the operation on the client's behalf. 
We were unable to resolve this during the meeting, further discussion on 
the list will be necessary.  However, there was noticeable sentiment in the 
room to choose the first alternative as being simpler.  Attempting to 
perform the operation may induce the server to attempt an iMIP connection 
which would likely not give acceptable real-time performance.

Supporting iRIP will require sysadmins to deploy new server daemons across 
their nets, and will require firewall modification to allow the protocol to 
pass between nets.  Some expressed the fear these changes would inhibit 
deployment of the protocol because it would potentially weaken a net's 
integrity.  It was proposed the iRIP command set be submitted as an 
extension to SMTP.  This avoids punching a new hole in a firewall for the 
new protocol.  In support of this proposal, it was noted that the fax WG is 
considering extensions to SMTP to support fax transmission across the net. 
The response to this was the fax WG's requests to extend SMTP are far from 
accepted.  Those familiar with email protocols thought it unlikely that 
such extensive changes to smtp to support iRIP capability would not be 
accepted by the email community.  AD Patrik Falstrom suggested that this 
idea may find a warmer reception in the metad group.

It is unclear when an ICALDATA is complete what should become of the 
recipient list in the object.  Should it be saved, or does the list reset? 
No resolution was apparent in the meeting.  This will require further 
discussion on the list.

Finally (as far as open iRIP issues are concerned), whether iRIP must 
return all error codes defined in iTIP is unclear.  The editors will seek 
the WG's advice on the list.

Schedule for iRIP Work

The editors anticipate releasing the next draft within 2 weeks.  Over the 
next 6 to 8 weeks the editors expect to make further revisions with the 
guidance of the WG.  They anticipate we'll be ready for WG Last Call in 
approximately 8 weeks.  By the 43rd IETF, an iRIP protocol should be ready 
for AD review prior to an IESG ballot.

CAP Requirements Draft

Having disposed of iRIP, the WG next focused its gaze on CAP requirements. 
The editors outlined their hopes and goals for the document.  They want to 
capture as many requirements as possible so the WG can review and agree on 
the requirements before proceeding to design the protocol.  They 
anticipate, as do many others within the WG, that a usable protocol will be 
subtle, complicated, and big.  Agreeing on the requirements should erect a 
sufficiently tall barrier to casual changes to the design in the future. 
The WG spent some time debating the future of the document once it is 
written.  This was returned to several times during the course of 
discussion of the requirements so far gathered.

The authors anticipate requirements will break down into five categories: 
Basic, Administrative, Component Management, Access Control and 
Notifications.  It was noted that Access Control refers to calendar object 
access, not access to calendar daemons themselves.  The authors polled the 
WG if the explanations were sufficiently detailed.  The WG seemed generally 
satisfied, although it was noted that the requirements while clear are not 
necessarily consistent.  Requirements are not yet sufficiently abstracted. 
As a result, some are stated as scenarios or examples rather than a 
explicit condition that must be met by the protocol.  Some worried the 
authors intended the scenarios to be normative.  Eventually it was 
understood they are to be explanatory, but that the scenarios currently are 
the vehicle to express requirements not yet fully conceived.

The authors then began to outline what constitutes the different catagories 
of requirements.
Basic requirements include calendar object manipulation such as 
add/modify/delete actions.  Requirements for the connection between the CUA 
and CS are considered basic.

The WG noted requirements for Searching Calendars will be necessary. 
Operations such as discovery, lookup and search should be included.

Notifications should support 2-way communication between client and servers.

Protocol Security requirements must cover 3 areas.  The protocol must 
provide for authentication between clients and servers.  It must be 
possible for clients and servers to identify each other.  Finally, the 
protocol must provide a means to determine if particular actions are 
authorized.

The CAP requirements authors offered to keep our ADs apprised of the WG's 
discussion of the requirements.  AD Patrik Falstrom noted that our WG's 
approach to setting requirements before embarking on design has not been 
widely used within the IETF to date.  Others will watch our progress with 
interest.

To sum up the requirements discussion, the authors expect to have a new 
requirements draft prepared in time for the 43rd IETF meeting.  They expect 
to be able to enumerate major sections of the requirements by Oct 9th. 
They will continue considering comments until Nov 25th.  Comments after 
that date will need to be included in the revision to follow the next 
meeting.  While it is not necessarily true the requirements document must 
become an RFC of the IETF, it certainly should have a strong role in 
shaping CAP's design.  Deviating from the requirements must not be entered 
into lightly.  A number expressed the hope this would become an 
informational RFC for the benefit of future implementors.

Finally, the model document author agreed to resurrect the model document 
draft, as it has expired.  However, he made no promises on when this feat 
would be accomplished.

Chairman's Summary

iCalendar, iTIP and iMIP are in the hands of the RFC Editor.  Their 
issuance as RFCs is imminent.  Locate will be presented to the ADs for 
their review.  Within the WG, iRIP requires further revision.  The WG must 
provide additional review, commentary, and revision for CAP Requirements. 
It was proposed that SCAP be removed from our Charter.

With our agenda completed, the chairman adjourned the meeting.

best,

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------