Re: proposed IETF calsch WG charter revision

On Wed, 25 Feb 2004, George Babics wrote:

>   RFC 3283 is more of an overview of the calendaring standards and not
>   necessary only for calendar system designers. How about:
>
>     An informational document (RFC 3283) provides an overview of the
>     above standards and of CAP.

OK.

>   I am not sure if the goals of the working group are clear enough.
> Is it only to finish CAP and to update the existing RFCs? What
> goals would we have to achieve in order to close this working group?
> Would finishing CAP be enough?

Finishing CAP (one way or another) could be enough.  As I mentioned, this
would leave dangling the status of iCal, iTIP, and iMIP.  The theory of
IETF process is that the community implementing and using a technology has
an interest in having its specifications progress through the maturity
levels to Full Standard.  Along the way bugs are fixed, unused features
dropped, extensions written, domains of use profiled, implementations
surveyed, etc.  None of that is required for folks to write interoperable
implementations around a spec, but these evolutionary steps have been
common across many IETF areas.  RFCs 2445-7 are coming up on 6 years old,
and are as good as they ever were, but also no better.  Application-area
specs are somewhat different than other lower-layer specs in that nothing
(in the IETF at least) depends on them, so there's no pressure to advance
in maturity so that dependent specs can also advance.  So it's up to this
community to decide how and whether to push those specs forward.

> > Goals and Milestones:
> >
> > Jun 04	  	Submit Calendar Access Protocol document to IESG
> >                 for consideration as a Proposed Standard.
>
>
> I think this may be optimistic, unless activity picks up, and we can
> agree on the remaining open issues for CAP. Should we put out a 'last
> call' for open issues?

I think I just did that in my "where we're at" note.

> For instance, we can ask people to post their issues before a certain
> deadline, so that we can compile a list. After the deadline, we would
> only add new issues to this list by consensus or if they are clearly
> important?

I'm hoping to talk deadline with the ADs in Seoul.

> > Nov 04          Submit iCalendar, iMIP and iTIP revisions to IESG for
> >                 consideration as standards-track.
> >
>
> This one may be too optimistic. Do we need at least two independent
> implementations that implement all the musts in these standards in
> order for the docs to be standards-track?

This is a requirement for Draft Standard.  That's why I didn't specify
which level in that milestone.  If significant changes are made to
Proposed Standard specs, the revisions have to start life at Proposed
again, which wouldn't require implementation reports.  If folks would like
to argue for taking 2445-7 to Draft Standard (and commit to doing the
work), I'd be happy to write that kind of charter language and milestones.

 - RL "Bob"