Re: proposed revised charter for IETF calsch WG (fwd)

interesting to see the direction the IETF WG on calendaring and 
scheduling is heading.

[[
The good news is that we can probably improve iCal greatly by 
simplifying it, rather than making it more complex.
]]

Libby

---------- Forwarded message ----------
Date: Sat, 31 Jul 2004 04:07:31 -0400
From: Nathaniel Borenstein <nsb@guppylake.com>
To: IETF calsch WG <ietf-calendar@imc.org>
Subject: Re: proposed revised charter for IETF calsch WG


On Jul 30, 2004, at 7:08 PM, Doug Royer wrote:

> I do not think that RFC02445-7 have significant changes.

Alas, I disagree.  RFC 2026 spells out in detail the requirements for advancing 
a protocol to Draft Standard status, and the current RFCs don't even come close 
to fulfilling them.  A couple of relevant excerpts from Section 4.1.2:

    A specification from which at least two independent and interoperable
    implementations from different code bases have been developed, and
    for which sufficient successful operational experience has been
    obtained, may be elevated to the "Draft Standard" level.
     .........
    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

The just-concluded-today Interop of the Calendaring and Scheduling Consortium 
was interesting in many ways (as will be reported at the WG on Tuesday and to 
this list) but if there's one thing it showed very clearly, it was that there 
are multiple "options and features" that have not been demonstrated to 
interoperate, and possibly some that haven't yet been implemented once.

I hate to bear the gloomy message, but I think there is a lot of accumulated 
wisdom embedded in the IETF process.  We've got some serious work to do before 
iCal is worthy of Draft status, which (according to RFC 2026, same section) 
indicates "a strong belief that the specification is mature and will be 
useful."   As long as vendors are still writing new adapters to deal with each 
others' varying flavors of iCal, I find "mature and useful" to be a bit of a 
stretch.

The good news is that we can probably improve iCal greatly by simplifying it, 
rather than making it more complex.  More on that Tuesday, if not sooner.   I 
must sleep before yet another spam conference in the morning...  -- Nathaniel

Received on Monday, 2 August 2004 03:55:12 UTC