vCal vs. new (was "RE: Quick comments on the "sch" and "csct" drafts")

[Jay Batson <JBatson@xxxxxxxxxx>]

On 12/9/96 at  3:40PM Alec Dun said:
>vCalendar only allows one daylight & one standard time shift, which
>means I can effectively only have a recurring meeting that lasts a year.
> ...
>Can't we just agree on this one thing?  I don't understand why it is
>contentious for you?  It doesn't seem like it will break vCalendar
>backward compatibility or anything... 

For the record, as the development executive at one of the "Vendors who 
have implemented vCalendar", I'm not stuck on going with particular 
vCalendar semantics *SIMPLY* because we've already written the code.  If 
the best thing for the spec requires me to rewrite code, so be it.

I'll even be willing to "sunset" my *existing* vCalendar support.  Why?  
Two reasons:

a)  All the code we have is in products that are in"public beta".  So I 
have an arguable case for dropping it when I shift.

b)  Customers -- and the stock market -- aren't going to reward me for 
supporting the vCalendar spec.  They'll likely reward me for selling 
software that "Supports the Internet Calendaring spec", though.

This is NOT to suggest that I'm bashing the vCalendar methods and 
specifications.  I'm only saying "Don't choose vCalendar because it 
supports an installed base."  I mean, c'mon -- the age of the products 
with vCalendar support is measured in single digit months.  Let's get some 
perspective about the need to support some mythical millions of users....

-jb