[Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence set, suggested rewording)

[Tim Hare]

In my opinion, for scheduling to work we need ONE way to exchange scheduling
information (including free/busy) in terms of what 2445 components and
properites are used and their syntax (do I mean semantics here?). That's the
only way to achieve interoperability.  If a particular implementation wants
to use other components and properties within itself, to provide
"competitive advantage", that's OK; even if that occurs inter-server between
two instances of the same vendor's software. But I maintain that _true_
competitive advantage will come to those that can sell us servers that "just
work" with any other entity that we deal with, and that's only going to
happen if we have one simple scheduling protocol.

Tim Hare
Interested Bystander, Non-Inc.
-----Original Message-----
From: ietf-calsify-bounces at osafoundation.org
[mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of Cyrus Daboo
Sent: Wednesday, May 31, 2006 11:15 AM
To: Eliot Lear; George Sexton
Cc: ietf-calsify
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence
set, suggested rewording)

Hi Eliot,

--On May 31, 2006 5:09:32 PM +0200 Eliot Lear <lear at cisco.com> wrote:

> I've read a whole lot of documents and written a ew, and I can tell you
> that 2445 has a huge number of examples, perhaps too many.  We need to
> balance demonstrating the functionality with forcing people to read
> through an encyclopedia.  It would be good if we could combine examples
> and point out relevant components.

2446 has even more examples than 2445. Those are used to directly 
demonstrate the various scheduling scenarios that can occur. The question 
is are they meant to be 'normative' in the sense that they define the 
'correct' way to so things, or are they only an example of one way to do 
it. One of the problems with 2445/2446 etc is that there are often multiple 
ways to do the same thing (particularly when it comes to recurrences and 
scheduling with multiple people) and that has lead to poor interop. So 
should the new specs try to 'bless' one approach as being the 'correct' way 
to do things, or merely the best way to achieve interop?

-- 
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify at osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify