IETF calsch WG: where we're at

At the WG meeting at IETF 58 in Minneapolis in November 2003, there was
discussion about the state of the WG, and its prospects for concluding
successfully.  A report regarding this discussion, and various other
intended changes, was sent to the list (by Nathaniel Borenstein, thanks to
him for doing that) after the meeting.  This note is to let the WG know
what has and hasn't happened, and to suggest where we're at and what needs
to be done.

Regarding action items from the IETF 58 discussion:

  I have been designated as co-chair replacing Bob Mahoney (and thanks,
  Bob, for serving as co-chair).  I have to apologize for not being able
  to give the WG adequate time since then.  I expect to devote more energy
  to it from this point on.

  Regarding the proposed change of editor for the CAP document, Nathaniel
  wasn't able to do this, so Doug Royer continues as editor, and has
  submitted the cap-12 draft (thanks, Doug).

  It was proposed that a revised WG charter be produced to describe work
  on revising RFCs 2445-2447 as well as completing CAP.  I will forward
  a proposal on this to the list separately.

  Lisa Dusseault volunteered to produce a draft on calendar access via
  webdav, and that was done in December (draft-dusseault-caldav-00.txt,
  thanks, Lisa).

  There was a suggestion from the Area Directors that there be a deadline
  by which this WG either make progress towards its milestones (basically,
  publishing the CAP spec) or be shut down; with the possibility of a BoF
  to initiate new work in the calendar space (eg work on caldav).  I think
  it's fair to say that neither has much progress been made, nor has a
  formal deadline been set.

An ongoing issue has been keeping track of issues with CAP (and with the
other WG docs) so that these can be discussed, resolved (with rough
consensus) and not rehashed.  A bugzilla repository was set up for this
purpose by Helge Hess (http://bugzilla.opengroupware.org/, thanks Helge),
but hasn't seen much use yet.  While bugzilla is fine for some things, I
think there is still a requirement for a standalone issues list, at least
for our active work items (that is, at this point, the CAP document); but
we have not identified someone to maintain this (volunteers welcome,
please contact the chairs).

Clearly the highest priority task for the WG is completion of CAP, i.e.,
submitting it to the IESG for consideration as a Proposed Standard.  The
step prior to that is conducting a Working Group Last Call on this
document.  I think that for a protocol document to be ready for Last Call
it must be feature-complete and have no significant unresolved normative
issues.  That is, there may still be known editorial fixups to do, but no
known technical fixups.  Obviously what is "significant" is a matter of
judgement, but some combination of affected lines of specification text,
affected lines of implementation code, and affected deployments/users is
taken into account, all of which should add up to "not very much".

So the question at hand is whether there are any known significant
normative issues with draft-ietf-calsch-cap-12.txt that need to be
resolved before asking for WG Last Call (yes, a pre-last-call last-call).
Let me suggest that the process for raising these be to submit them to the
bugzilla repository, get an ID, and then send a note to the WG list
referencing that ID, and describing the issue.  I would prefer that issue
discussion happen on the WG list rather than in bugzilla.

It has been suggested, I think, that finishing CAP may depend on revising
RFC 2445 (and maybe 2446/7) first.  This would be a big shift to make, so
would not be undertaken lightly.  But if this is needed it should be done.
Please comment on this if you have a strong opinion either way (the
default is to proceed with CAP as is).  In any case, IETF process calls
for the calendar-related standards RFCs to either progress along the
standards track (they're all at Proposed Standard now) or risk being
re-labelled as Historic.  So work on revising these RFCs will have to be
undertaken at some point (or else abandon the technology), hence the
proposed charter revision to do this work.

In order to be ready for submission to the IESG, the chairs have to be
assured that a document, in this case the CAP document, has received
adequate review.  In my view, this means comments from implementors either
raising issues or stating that the spec is implementable as is.  In the
absence of evidence of review of the document, it can not go forward from
the WG for consideration as a Proposed Standard.  Publishing the document
as an Experimental RFC is one path that can be taken instead.

So, in case this message isn't clear: if you have an interest in seeing
CAP become an IETF standard, review the document now and comment on it.
If you are intending to implement CAP, please comment on the results of
your implementation experience.  If you are waiting around for CAP to "be
finished" before checking it out, figuring someone else will fix it, you
are making a mistake: please review and comment now, or the document may
not go forward.

Obviously there has been discussion about calendar access other than CAP,
including the submission of caldav.  Discussion of the caldav draft on
this list is encouraged (with the reservation that it might move elsewhere
if there is lots of traffic).  If you have other approaches to offer,
please check with the chairs before starting a thread, as we don't want to
spend time on everything under the sun.  But consideration of future
directions is particularly important for this WG given its rather delayed
state.

As mentioned, there will be a one-hour WG meeting in Seoul; I'll send the
proposed agenda separately.  I apologize (again) for the lateness of this,
and understand that many interested parties may not be able to attend.  We
will do the text conference thing which may help some to participate
remotely.  As always the list is open for comments.

 - RL "Bob"