Subject: [IPTEL] Current thinking on CPL/iCalendar

From: John Stracke <[email-masked]>
Date: Mon, 19 Mar 2001 22:04:36 -0600

We talked about the CPL/iCalendar issue at the calsch dinner
tonight.  The outcome (such as it is):

   * Some of us, at least, like the idea of cutting back
     iCalendar's RECUR semantics to match the CPL semantics (as I
     described in the informal Draft I posted last Monday).
   * The changes:
        o In order to prevent overlapping instances, which
          complicate evaluation:
             + Recurring events cannot have a DURATION over 24
               hours.
             + The interval between instances must be less than
               24 hours.
             + All the RECUR parameters for sub-day values (e.g.,
               BYSEC, BYMIN, BYHOUR) are removed.
        o COUNT and BYSETPOS are removed, so that you don't have
          to step through the instances linearly in order to
          evaluate the rule.
   * Possible impact on existing (or potential) applications:
        o No overlapping instances--can anybody provide a
          plausible scenario where you'd want them?
        o Unable to schedule sub-day recurrences--is this a
          problem? They were apparently put in for people who
          wanted to schedule bandwidth allocation at a very fine
          granularity; is anybody still interested in this?
        o COUNT can be replaced with UNTIL.
        o BYSETPOS can be replaced with EXDATEs.

So.  Please think it over so we can discuss it in the meeting
Wednesday.  (If you're not here, it'd be helpful if you can post
before the meeting.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |This space intentionally not left blank.     |
[email-masked]|                                             |
\==============================================================/

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: David Madeo <[email-masked]>
Date: Tue, 20 Mar 2001 08:01:46 -0500

>     + The interval between instances must be less than

I'm assuming this is reversed and should be "more".  Otherwise my
weekly meetings are going to be a bit difficult.
A counter example would be the pill that I have to take every four
hours.

>           plausible scenario where you'd want them?

Our training dept schedules multiple instances of the "same" class
which sometimes overlap.  I could easily be swayed by the argument
that there should be multiple "threads" on a per instructor basis, or
perhaps by room.  Just pointing out one possibility.

>           granularity; is anybody still interested in this?

My pill example

Wish I could be there...

dmadeo

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Mar 2001 08:30:32 -0600

>A counter example would be the pill that I have to take every four

Question: Is not the requirement for O(1) that the interval between 
events have to be longer than the length of the event itself?

I.e. removing support for sub-24h recurrances seems too arbitrary if 
not really needed.

>perhaps by room.  Just pointing out one possibility.

The need for non-overlapping events is the largest requirement for 
O(1) isn't it?

Because of this I think it should be stated as the main goal for these changes.

    paf

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Mar 2001 09:53:17 -0800

One related item discussed was whether some elements (such as COUNT) can
be retained if CPL-implementing servers are "willing" to convert COUNT
to UNTIL when the CPL script is uploaded, so that the actual call
handling is still O(1). This obviously makes sense only if the upload
frequency is significantly lower than the call frequency.

---

From: Steve Mansour <[email-masked]>
Date: Tue, 20 Mar 2001 07:04:35 -0800

> events have to be longer than the length of the event itself?

yes, that is the spirit of what we're after.  Even durations must be shorter than
the recurrence interval. It turns out that one of the editor's implementation was
driving the need for the 24hr number in the proposal.

> The need for non-overlapping events is the largest requirement for

Overlapping events are common.  I think the need is for non-overlapping
recurrences.

-Steve

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Mar 2001 09:16:31 -0600

At 07.04 -0800 01-03-20, Steve Mansour wrote:
>yes, that is the spirit of what we're after.  Even durations must be 
>shorter than the recurrence interval. It turns out that one of the 
>editor's implementation was driving the need for the 24hr number in 
>the proposal.

So, you are saying that my suggestion to change the 24h limit to 
instead a comparison between the length of the event and the length 
of the interval?

>Overlapping events are common.  I think the need is for non-overlapping

Of course. My mistake. This was what I wanted to write...

    paf

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 09:29:05 -0600

> I.e. removing support for sub-24h recurrances seems too arbitrary if

We thought about that; but a straightforward limit like this is much easier to
explain to a user, and incorporate in a UI.

> The need for non-overlapping events is the largest requirement for

Yes.

> Because of this I think it should be stated as the main goal for these changes.

OK.

|eCal Corp.      |Think of it as evolution in action.          |

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 09:33:21 -0600

David Madeo wrote:

> I'm assuming this is reversed and should be "more".

Yes.

> Otherwise my

Yeah, we thought of that one.  The problem is that such usages are
really the 5% case; and supporting them complicates the 95% case.  Your
every-four-hours event could be implemented as six related
every-twenty-four-hours events--ugly, but the current recurrence grammar
is even uglier.

> perhaps by room.

Yes, that's what we were thinking of.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I'm not imaginary. I'm ontologically challenged.|
[email-masked]|                                                |
\=================================================================/

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Mar 2001 11:37:48 -0800

> 
> You are the ones making the decision, but I think you should think
> very hard wether you want this kind of limitation (a fixed limit)
> when the overlap is the most important thing, and the problem you try
> to solve.
> 
> An application can still prohibit the user from entering whatever if
> it wants to...

I don't think the latter option is viable. If application A allows it,
but application B doesn't, then shipping CPL or calsch elements from A
to B is going to be very confusing to the user. How would the B user
change the interval from 4 to 5 hours?

As I said before, the O(1) requirement can be relaxed somewhat if
reasonable expansion or translation is possible when the CPL arrives at
the server. The question is whether any existing UI support these
corner-cases.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Mar 2001 09:41:57 -0600

>explain to a user, and incorporate in a UI.

...but it means that you can never have recurrance rules which handle 
the "medication problem"...or a recurrance rule which tells when the 
busses are leaving for a social event (starting 17:00, every 15 
minutes, 5 times).

    paf

---

From: Steve Mansour <[email-masked]>
Date: Tue, 20 Mar 2001 07:43:36 -0800

> instead a comparison between the length of the event and the length

That is what I would prefer. Seems like the right thing to do. I know that
there were people who wanted recurrence intervals less than 24 hours when we
were writing iCalendar.  Seems like it would be a bad move to pull that
capability away -- especially if we have no alternative way to describe
recurrence intervals less than a day.

As far as removing the COUNT, this is bad but I understand their reasoning,
and at least there is a way to get pretty much the same functionality using
UNTIL.  I will be interested to see how the group at large reacts to this
proposal.

-Steve

---

From: Steve Mansour <[email-masked]>
Date: Tue, 20 Mar 2001 07:55:17 -0800

> explain to a user, and incorporate in a UI.

That is true. But a UI of an application can enforce the 24 hr limit without imposing
that limit on iCalendar.

-Steve

---

From: [email-masked]
Date: Tue, 20 Mar 2001 08:16:52 -0800 (PST)

> > explain to a user, and incorporate in a UI.

I don't agree. Part of explaining a limitation is justifying it. It may be a
bit easier to say or imply in a UI that short recurrances aren't allowed, but
it is pretty hard to justify. Whereas prohibiting overlap may manifest in a
more obvious way but seems a lot more natural.

> busses are leaving for a social event (starting 17:00, every 15

... or when the tour starts every 15 minutes. ... or when the presentation at
the trade show begins 5 minutes after the hour, every hour. ... or when the
film loop restarts every hour on the hour. Heck, they make single-hand standup
clocks specifically to show this sort of stuff. It is a _common_ schedule for
things to have.

> when the overlap is the most important thing, and the problem you try

I agree.

				Ned

---

From: [email-masked]
Date: Tue, 20 Mar 2001 08:43:17 -0800 (PST)

> change the interval from 4 to 5 hours?

There's always a problem if we impose a requirement on what's allowed
in the protocol and some implementations don't conform to it. I see
little difference between the problems that arise when an implementation
fails to prohibit overlaps and the problems that arise when an implementation
fails to respect a minimum-time-between-occurances restriction.

				Ned

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Mar 2001 15:29:13 -0800

> fails to respect a minimum-time-between-occurances restriction.

Agreed; however, if no or hardly any implementations support a
particular feature it is standard IETF practice to dump it (indeed, the
two-interoperable-implementations-rule pretty much requires it). For the
corner cases, I would consider likelihood of interoperability trumping
conciseness in event specification.

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 13:56:48 -0600

[email-masked] wrote:

> I don't agree. Part of explaining a limitation is justifying it.

OK, "express" rather than "explain".

> Whereas prohibiting overlap may manifest in a

Yes, but it's going to be hard to build the right affordances into the UI to make it
clear what the user can and can't do.

Of course, if Alan's work to come up with an algorithm that can handle overlaps
succeeds, then this becomes moot.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Lollygaggers will be shot on sight!" "I didn't|
[email-masked]|say that!" "I was paraphrasing."               |
\================================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 13:53:22 -0600

> That is true. But a UI of an application can enforce the 24 hr limit without imposing

Yes and no.  An app which does not let the user create sub-day recurrences may have
trouble understanding sub-day recurrences.

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 13:57:38 -0600

[email-masked] wrote:

> I see

But detecting overlap is harder, so "fails to prohibit overlaps" is a more
likely failure mode.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"The Reality Check's in the mail." --L. Peter|
[email-masked]|Deutsch                                      |
\==============================================================/