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