Subject: Re: RECAP & Questions of CPL RECUR Issues.

From: [email-masked]
Date: Thu, 17 May 2001 11:53:20 -0400

John replied on 05/17/2001 10:19:07 AM:
> > Also, feature removal of already demonstrated interop features
> > is not good is it??
> 
> Again, it is not forbidden.  If we can't get two interoperating
> CUAs that support the entire RECUR syntax, we'll have to cut
> something.

Removing the subcomponent in this case would suite the intent of interop 
testing.  If 2 independent implementations have demonstrated that they use 
and support it, WHY cut that?!?!?  The intent is to cut stuff that is not implemented/supported, not stuff that is! 

Still Im not buying the argument that cutting is necessary yet.  As we 
have seen from our own internal WG discussions, clarifications (and some 
minor tweaks) are in order to make the recurrence grammar less ambiguous 
and to make interop easier. 

Nearly all, if actually all, of the recurrence grammar subcomponents have 
been implemented by at least 2 different implementions that I can think of 
so what is there to really cut? 

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Graham Gilmore" <[email-masked]>
Date: Thu, 17 May 2001 12:11:42 -0400

----- Original Message -----
From: <[email-masked]>
To: "John Stracke" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: 17 May, 2001 11:53
Subject: Re: RECAP & Questions of CPL RECUR Issues.

> and support it, WHY cut that?!?!?  The intent is to cut stuff that is
not implemented/supported, not stuff that is!
> so what is there to really cut?

    Isn't the whole point of pushing for these standards to make it
easier for people looking to implement something that can communicate
with other implementations?  What's the point of having a standard
that's so complex and difficult that only the largest/most resourceful
organizations can actually create a working implementation?  How many
vCalendar (1.0) implementations exist out there simply because iCalendar
was seen as too hard to implement?
    Excuse my idealism....

    Graham

---

From: John Stracke <[email-masked]>
Date: Thu, 17 May 2001 14:47:50 -0400

[email-masked] wrote:

> > If we can't get two interoperating
> Removing the subcomponent in this case would suite the intent
> of interop testing.  If 2 independent implementations have
> demonstrated that they use and support it, WHY cut that?!?!?
> The intent is to cut stuff that is not implemented/supported,
> not stuff that is!

To reach Draft Standard, there need to be two implementations
which implement the *entire* specification.  You can't
cherry-pick; you can't say, "A and B support X, and C and D
support Y, so we keep X and Y" (unless X and Y are optional).

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Know your limits, then destroy 'em.          |
[email-masked]|                                             |
\==============================================================/