Subject: proposed IETF calsch WG charter revision

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 25 Feb 2004 13:11:54 -0800 (PST)

Below is a proposal for a revised charter for this WG, reflecting our
completed work, new milestones, and the proposal to revise iCalendar etc.
It is obviously minimal, but is a starting point.  The milestone dates are
a shot in the dark.  Comments please.

 - RL "Bob"

---

Calendaring and Scheduling (calsch)

Last Modified: 2004-nn-nn
Chair(s):
  Pat Egen <[email-masked]>
  RL Bob Morgan <[email-masked]>
Applications Area Director(s):
  Ned Freed <[email-masked]>
  Ted Hardie <[email-masked]>
Applications Area Advisor:
  Ned Freed <[email-masked]>
Mailing Lists:
  General Discussion: [email-masked]
  To Subscribe: [email-masked]
  In Body: SUBSCRIBE/UNSUBSCRIBE
  Archive: http://www.imc.org/ietf-calendar/mail-archive/

Description of Working Group:

The calsch WG develops standards to enable heterogeneous calendaring and
scheduling products and systems to interoperate.  Completed
standards-track work includes a specification for calendar objects and an
associated MIME type (RFC 2445, iCalendar), a transport-independent
protocol for exchanging and operating on calendar objects (RFC 2446,
iTIP), a message-based transport for iTIP (RFC 2447, iMIP), and definition
and discovery of calendar URIs (RFC 2739).  An informational document
provides guidance for calendar system designers in using these protocols
(RFC 3283).

An additional standard protocol in the suite provides access to and
management of calendar objects in a real-time client-server fashion; this
is the "Calendar Access Protocol" (CAP).  Submission of CAP as a Proposed
Standard is a key work item of the WG.

Since their publication, there has been considerable experience with the
protocols and objects defined in RFCs 2445-2447.  The WG will update these
RFCs as required to reflect changes based on this experience.

Goals and Milestones:

Jun 04	  	Submit Calendar Access Protocol document to IESG
                for consideration as a Proposed Standard.

Jul 04	  	Submit Internet-Drafts for iCalendar, iMIP and iTIP
                revisions

Nov 04          Submit iCalendar, iMIP and iTIP revisions to IESG for
                consideration as standards-track.

---

From: George Babics <[email-masked]>
Date: Wed, 25 Feb 2004 17:19:46 -0500

I glad that we are updating the charter. Thanks!

See my comments inline.

> provides guidance for calendar system designers in using these protocols

  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.

> RFCs as required to reflect changes based on this experience.

  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?

>                 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? 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?

> Jul 04	  	Submit Internet-Drafts for iCalendar, iMIP and iTIP

Again we need a list of open issues. I believe someone used to maintain
such a list, but I do not know what has come of it.

>                 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?

George

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 25 Feb 2004 15:38:25 -0800 (PST)

>     above standards and of CAP.

OK.

> 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.

> 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

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

> 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"

---

From: [email-masked]
Date: Thu, 26 Feb 2004 14:10:18 -0500

Looks good Bob

"RL 'Bob' Morgan" <[email-masked]> 
Sent by: [email-masked]
02/25/2004 04:11 PM

To
IETF calsch WG <[email-masked]>
cc

Subject
proposed IETF calsch WG charter revision

 - RL "Bob"

---

Goals and Milestones:

Jun 04                           Submit Calendar Access Protocol document 
to IESG
                for consideration as a Proposed Standard.

Jul 04                           Submit Internet-Drafts for iCalendar, 
iMIP and iTIP
                revisions