[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iptel and iCalendar
> -----Original Message-----
> From: Patrik Fältström [mailto:paf@xxxxxxxxx]
> Sent: Sunday, February 25, 2001 4:16 PM
> To: Jonathan Lennox; ietf-calendar@xxxxxxx; Jonathan
> Rosenberg; Henning
> Schulzrinne; John Stracke
> Subject: Re: iptel and iCalendar
> It would be good if this can be resolved, so we can put CPL to bed.
> I see the questions are two important ones:
> (1) Recurrence rules in IPTEL and iCalendar aren't compatible.
> I feel this is not a good thing for the community. This
> incompatibility will most certainly lead to problems when CPL is
> deployed. Yes, I see the arguments about O(1) from the IPTEL pepople,
> but my view is that this is not worth the problems we get with the
> incompatibility, and that the CPL draft should allow the full
> iCalendar spec for recurrance rules.
I really want to emphasize the importance of this O(1) requirement. CPL is
different than the typical iCalendar usage. In our application, clients, who
may be malicious, upload scripts to servers to execute. These servers are
high volume call processing engines. The primary design criteria for CPL is
that it was safe; that is, no CPL could cause unbounded execution. This is
important because of the large call volumes AND because we didn't want CPL
to introduce denial of service attacks. Thus, the O(1) requirement is really
important for this application.
> (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
> Example on where this can lead to a surprising behaviour is if you
> have an event which starts at 1AM, and has a duration of 4 hours. If
> this is "local time", the duration will probably be only 3 hours
> once, and 5 hours once a year -- because local time change timezone
> twice a year. If you want an event between 1AM and 5AM and explicitly
> the behaviour I talk about above, then you should use start and stop
> time. Reason for duration is that the duration should be exactly that
> every time.
> More specifically, I see that the lack of timezone is something which
> is a client issue, and one can easilly force the CPL client
> application to always add the timezone to the object. I.e. I see the
> ability to not have timezone is a request for a user to not being
> forced to enter a timezone.
> And, how do you map such a "floating event" back into iCalendar
> format when you don't know the timezone?
This one isn't critical. There wasn't any real debate on whether there
needed to be floating times in the spec. Perhaps Jonathan Lennox can
comment. My view is that I would have no problem making the timezone (either
as a tzid or tzurl) mandatory. Would that address this issue?
> 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
There was sympathy for an O(1) version of the recurrence rules from some of
the folks in calsch (John Stracke, at least), as something that would be
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050
http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000