W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > November 2003

Re: Status of the CALSCH working group (fwd)

From: Libby Miller <Libby.Miller@bristol.ac.uk>
Date: Fri, 7 Nov 2003 17:58:25 +0000 (GMT)
To: www-rdf-calendar@w3.org
Message-ID: <Pine.GSO.4.58.0311071752330.8685@mail.ilrt.bris.ac.uk>


A long message (from ietf-calendar@imc.org), but an interesting one I
think. There has been a lot of discussion recently on this IETF calsch
working group list about future directions for iCalendar, CAP
and related docuements. I've edited out the emails in the subject for
spam reducing purposes, but the list is online (though not easily
searchable):

http://www.ietf.org/html.charters/calsch-charter.html
http://www.imc.org/ietf-calendar/mail-archive/

cheers

Libby


---------- Forwarded message ----------
Date: Fri, 7 Nov 2003 11:48:18 -0500
From: Nathaniel Borenstein
Subject: Re: Status of the CALSCH working group

On Tuesday, November 4, 2003, at 07:06  PM, Satya Vempati wrote:

> Would it be possible to get someone like Nathaniel Borenstein to take
> the role of a co-editor (if he is interested)? It would help to have a
> seasoned veteran of the IETF process to help move things forward.

Well, I guess this is my clue to stop lurking....  so I'll apologize in
advance for the length of this message.

As many of you know, I have been coming up to speed on the CALSCH
working group for several months now, and have expressed a willingness
to try to help.  However, in the spirit of the Hippocratic oath --
"First, do no harm" -- I have been slow to volunteer for a particular
role, but I am definitely ready to do so now.  However, I'd like to
take a step back and point out where we are in the larger picture and
where we need to go.

The current debates all center around one particular document, the CAP
document, which Doug is struggling manfully to complete.  Completing
the CAP draft would be a great thing, but let's not kid ourselves about
where it leaves us:  the absolute best thing that can result from the
current efforts is the publication of an RFC that *might* be approved
as a Proposed Standard, thereby catching up to most of the rest of the
calendaring-related documents, none of which, I believe, have gotten
past that "first step" in the standardizations process.

There's still a long, long way to go, and I know that many of you are
rather discouraged, given how long this project has been under way.
Standards take a long time, and progress in calendaring and scheduling
at the IETF has been particularly tortuous.  I know that some good
people have simply burnt out along the way, and I'm not (deliberately)
volunteering to be the next one.  I don't want to jump in without a
path and plan to success, so I'm going to be a tad brutal in the next
paragraph, though I intend no offense or disrespect to anyone who has
been working on this challenging process.

It is my opinion that ALL of the CALSCH documents -- not just CAP --
need a lot of work.  A successful standard needs to be completely free
of ambiguity.  You don't get there simply by tending to the most
urgently yelled-about issues, you get there by comprehensively looking
for ambiguities and using extremely clear, consistent, and conscious
language for all of the specifications, especially with regard to the
MUST/SHOULD/MAY kinds of language and the existence of a complete
authoritative ABNF grammar of which the text is really only an
elucidation.

If I'm right, getting CAP out the door could be a pyrrhic victory.  If
it were up to me -- and I've been nominated to join the IAB, for
whatever that's worth -- I don't think I could support advancing CAP to
proposed standard as it stands, but I'm notoriously picky and wouldn't
have supported moving several of the other documents to that stage,
either, had I been involved at the time.  I want a lot more clarity and
a lot less ambiguity, or we're going to start having proposed standards
with incompatible implementations.  In any event, even if my
requirements are too demanding for "Proposed" status, I predict that my
concerns will be major problems later in moving the documents to Draft
and Full standard status.  (For reference, it took us a long time to
get MIME to Proposed status, but the process was *relatively* painless
and mechanical from then on because there really weren't that many
ambiguities left.)

Given this perspective, there's an argument to be made that the logical
thing to do is to "finish" the CAP document (for some careful
definition of "finish") and then open a whole new round of revisions to
the CALSCH documents, including CAP.  I would be willing to serve as a
document editor for such a round of revisions.  But in the meantime, we
have to either put CAP to bed or put it on hold for a whole new round.
One of the reasons I've been lurking quietly is that I had hoped to
postpone my more active involvement until CAP was finished, but I now
think that putting our recent discussion in the context of the larger
needs of CALSCH might actually help us figure out how to finish CAP.

To put it in perspective:  The CAP document describes an early stage
protocol with no functionally interoperating implementations (that I
know of).  This means that it WILL have mistakes in it -- there's no
substitute for building interoperable code for fleshing out those
mistakes.  So we don't have to believe that CAP is perfect for us to
sign off on it, because we know that it will simply provide a basis for
further experiments toward the goal of a fully interoperable protocol.
Remembering that perfection is not a requirement should be helpful.
Instead of perfection, I think we should be pursuing a somewhat more
modest goal, which is to identify and correct any deficiencies in the
current CAP spec that can be reasonably anticipated to cause major
headaches for that next round of standardization efforts.  It is my
preference to confine my own comments on CAP to that category of
problems that could significantly complicate the efforts that I am
volunteering to help lead  for the next round of CALSCH document
revisions.

Thus, with that ridiculous amount of prologue -- and with gratitude to
anyone who has read this far -- I now offer my own opinions about what
we need to fix to put this version of CAP to bed.  There are three
things that I regard as *potential* showstoppers, though not difficult
ones to fix:

Versioning:  The CAP-VERSION property as currently defined is simply
not adequate to allow us the possibility of gracefully introducing
incompatible changes in future versions.  As I contemplate an
involvement in such future refinements, I can't imagine a more
"showstopping" problem than this one.  FWIW, I speak from bitter
experience:  for those of you who don't realize it, "MIME-Version" has
an inadequate definition that almost certainly precludes *any* future
values other than 1.0.  I would like to see CAP avoid the same mistake,
as I think the cost would be much greater for CAP than it was for MIME.

CALSCALE -- I would like to either see us add a capability
specification for calendar scales and a special error code for
unsupported calendar scales, or I would like someone to convince me
that the absence of such scales isn't really a problem for future
extensions.  What we have right now tells us that there might be other
calendar scales, but doesn't really tell an implementation how to
behave if it encounters one.

ABNF -- There simply must be a complete ABNF for a standards-track
protocol, in my opinion.  However, I'm also not convinced that
releasing CAP as an Experimental RFC without such an ABNF would in any
way impede CAP's progress in the market.  In fact, publication as an
Experimental RFC might well be the smartest, fastest track for closure
on the current document.  I could support publication as an
experimental RFC if only my first two issues (CAP-VERSION and handling
of unrecognized CALSCALE values) are resolved.

There are a couple of more things I would really like to see cleaned
up, though I can imagine publication (especially as Experimental)
without fixing them:

"SCOPING" -- The issue discussed as "SCOPING" on the list concerns me,
but only as an easily-clarified ambiguity.  It seems that sometimes
when you say "SELECT VALARM"  (or SELECT whatever), you want only the
VALARM (or whatever), and sometimes you want the whole enclosing ical
body, including the time zone, product-id, method, cal-scale, the whole
kit and kaboodle.  I can understand -- barely -- why you might
sometimes NOT want the enclosing stuff, but surely you often do want
it, so either we need to be crystal clear that "everything" (properly
defined) is to be returned, or we need to provide two forms of the
request to get the two kinds of return.

VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems
to me that there are several ambiguities here.  I think that we must be
clear about a requirement that servers MUST provide "currently
accurate" freebusy information in response to an appropriate request.
And I'm definitely confused about why one would want to permit the use
of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the
ITIP syntax for requesting this information.

Finally, there are a couple of things that I am still confused about
after months on the list.  This doesn't necessarily mean there's a
problem, but it certainly makes me nervous -- at the risk of sounding
arrogant, if I haven't figured it out yet, I'm not optimistic that all
implementors will "figure it out" in a compatible way:

EXPAND and QUERYID -- I am having a hard time understanding how stored
queries can be useful without search wildcards.  Can anyone explain
this to me?

Alarms/SEQUENCE -- I remain confused: Can there be two identical
objects in the same calendar?  If not, we should clearly say so.

Anyway, I apologize for the length of this message and for its
appearance at such a late pre-Minneapolis moment, but since Satya has
honored me with the suggestion that I might be of help, I thought I
should try to lay out my current thinking as clearly as possible.  I
look forward to seeing as many as possible of you in Minneapolis!  --
Nathaniel
Received on Friday, 7 November 2003 13:02:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:12 UTC