Subject: RE: iptel and iCalendar

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2001 11:17:26 -0500

Comments below:

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Sunday, February 25, 2001 4:16 PM
> To: Jonathan Lennox; [email-masked]; 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 
> standard".

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
generally useful.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Bob Mahoney <[email-masked]>
Date: Mon, 26 Feb 2001 12:28:43 -0500

>Pat, can we use 15 minutes  if the CALSH agenda time to talk about this issue?

Pat won't be able to be in Minneapolis, so I'll be running the 
meeting.  I think we can commit to a 15 minute discussion at least, 
maybe more.

We also typically have a couple of meals where the available calsch 
folks get together and go over current issues in a more social 
setting.  I'll drop a note to the iptel folks above when we get a 
plan, but a Monday dinner has developed to be fairly common. 
Interested folks should feel pre-invited...  :-)

-Bob

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Feb 2001 09:10:17 -0800

>the folks in calsch (John Stracke, at least), as something that would be

The key requirement for me and IESG is that we really would like the 
recurrance rules to be the same in CPL and iCal. That way events can 
be moved between the two systems without any problems (which is what 
is said in the CPL draft).

I don't take any position on whether O(1) is needed or not (but I 
sure hear strong requirements from the IPTEL people).

I further don't want a fight here, and especially not via email.

IPTEL people can you have some people there during the CALSH meeting?

If the solution is that CPL really will use a subset, I want that to 
be a very consious decision by both(!) wg's and that must be 
documented in the CPL draft. I.e. even if IESG (including myself) 
really want the same rules. If that is not possible for various 
reasons -- fine.

I just don't want this compatibility/incompatibility issue to pass 
too easy. Noone should be able to come afterwards and say "hey, I 
didn't see that decision".

So, let's just have this message of mine as a wakeup call. Let's talk 
in Minneapolis.

    paf

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 26 Feb 2001 15:03:03 -0500 (EST)

> important for this application.

I agree, with one proviso: I'd be willing to relax the subsetting for cases
where the recurrence rule requires an *off-line* one-time runtime greater
than O(1), provided that some internal data structure can be produced on
which the *on-line* recurrence can be evaluated in O(1) time.  (The example
I'm thinking of is the conversion of COUNT to UNTIL.)

Not all the iCalendar recurrence rules can be transformed this way, though,
unfortunately.  (Particularly: very-long-duration events, and BYSETPOS.)

> as a tzid or tzurl) mandatory. Would that address this issue?

I don't have a problem with this.

(On a related note: is there any progress on creating a standardized TZID or
canonical TZURL database?)

-- 
Jonathan Lennox
[email-masked]