Subject: Re: Implementors' Guide

From: [email-masked]
Date: Sun, 11 Jun 2000 14:44:44 -0400

Bob:
If the information/commentary is has a technical basis that will assist 
the implementor in providing a product that interoperabtes with another 
product that implements the specifications or if the commentary explains 
technical rationale for particular parts of the specification, for example 
why TZID is required on repeating events because the start and end my 
cross a time zone boundary, then this makes sense. 
However, if the commentary merely summarizes our usual long ranting 
discussions from the mailing list or IETF meetings, then I agree with 
Bruce - - Keep it out.
On the other hand, if the commentary offers implementation tutorial on how 
to implement an interoperable calendaring and scheduling product, then I 
might also agree with Bruce. How you or I would implement such a product 
is not normative. But if the commentary or analysis of a particular 
implementation issue will help lead to more interoperable iCalendar based 
implementations, then by all means, include the text.
I wouldn't have thought, by looking at the charter that we are a forum for 
general calendar implementation discussion, but rather a forum for 
calendaring and scheduling interoperability. This ought to be the sole 
criteria we use in triaging information for this document.
"Does this item help to provide interopability with another implementation 
of these specifications?" YES, it goes in. NO, it doesn't.
Don't others agree?
-- Frank

---

From: Bob Mahoney <[email-masked]>
Date: Sun, 11 Jun 2000 15:01:37 -0400

>"Does this item help to provide interopability with another 
>implementation of these specifications?" YES, it goes in. NO, it 
>doesn't.

I'd advise people to wait their comments until they see text that 
they have issue with.  We have a lot of work to do, and we shouldn't 
spend too much time worrying about text that may someday be written 
by someone, if perhaps they actually get it done...  :-)

We'll get a draft out as soon as we can, and then the form of the 
document might be useful to talk about.  Right now, what will help us 
get this out are comments from developer's concerning things they'd 
wish they'd known before coding, things that were confusing in the 
published drafts, or other sorts of coding experience worth sharing.

-Bob