[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iptel and iCalendar
John Stracke wrote:
> Patrik Fältström wrote:
> > (2) Recurrence rules in IPTEL can be specified in local time without
> > a time zone (what is called floating times) and this can lead to
> > unexpected behavior
> Can someone from IPTEL explain why this was needed? It's not clear to me how it
> would be useful for CPL scheduling. For user events, this is sometimes useful ("I
> want to be reminded to take my medicine every day at 7 AM, local time, wherever I
> am"); but it's not as if the telephony switch is going to migrate from timezone to
There is a somewhat related problem, as in "I don't want to receive
calls from 11 pm to 6 am, wherever I am (as I'm asleep during that
time)", but the server will have a hard time knowing which time zone
each end system is in, so I doubt that this is useful in practice.
> > Last point, I have not seen anyone in the CALSH wg commenting on the
> > needs for O(1) from the CPL people, like "you can do it this way
> > instead" or "we don't think that is important" or even "oooops, we
> > made a mistake, we have the same requirement and need to update our
> > standard".
> In addition, there's the problem of how to build a comprehensible UI that
> represents all the capabilities of iCalendar recurrence rules. My fear is that
> people are going to subset the syntax to make the UI workable, and they'll subset
> it *differently*.
> I was going to write up a Draft with Jonathan Lennox, proposing a uniform subset
> that's O(1) and simple to work with; but I got tied up with other work last week,
> and now I've missed the new-draft deadline.
To amplify: from all I can tell, nobody has stepped forward and said
"yes, we implement all of the recurrence rules". Thus, consider IPtel
doing CALSCH doing the favor of identifying the features that could be
included when moving to Draft Standard :-). I think it would be really
confusing if IPtel includes all of them, then CALSCH tries to go to
Draft, discovers "oops, there aren't two implementations for much of
this, so we'll have to strike them from the draft". While calendars
generally have a reasonably close association between clients and
servers (i.e., as long as I know what my local server supports, I can
work around limitations), IPtel scripts are more likely to be "far away"
from the user, possibly moving to different servers as I roam between
providers. Having a script that works on one server but triggers a
"sorry, we don't implement this obscure recursion" on another is a
customer support nightmare.
If the CALSCH community feels the need for the non-O(1) features, I
would be much more comfortable with extracting them into an explicitly
labeled extension of some sort. Not ideal, but at least it provides a
binary rather than multi-step interoperability.
Henning Schulzrinne http://www.cs.columbia.edu/~hgs