Subject: Re: Current thinking on CPL/iCalendar

From: [email-masked]
Date: Tue, 20 Mar 2001 16:33:12 -0500

Steve replied:
>> Similar example to Daves:
>> A theatre lists a movie once but it may have overlapping show times.
>
>but they will be in different locations.

They may be in different physical theatres (#1, #13, etc) but the LOCATION
would still be "Westford Local Multiplex at Big Mall" for all showings...

As a movie goer I only care about the building, NOT the room in the
theatre...  (Would not you not go to a movie at a convenient time just
because it was 1 room down from your favorite one??)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Alan Davies <[email-masked]>
Date: Wed, 21 Mar 2001 08:55:45 -0600

One problem is the complex interactions and ambiguities
that occur when using different combinations of BY* and
FREQ. Eric highlighted some issues, as well as suggesting
some restrictions on which BY* parameters can be used
when:

http://www.imc.org/ietf-calendar/mail-archive/msg05424.html

Perhaps it would help if these restrictions were worded more
generally, to make them more restrictive?

--Alan

At 07:02 PM 3/20/01 -0500, you wrote:

> >John Stracke wrote (snipped from a longer note):
>However, we may be able to achieve O(1) without banning the sub-day
>recurrences.  If so, then we still have the issue of usability; the current
>RECUR grammar is extremely complex, far too complex to express in a simple
>UI.  This means that we'll get implementations that support only subsets
>(there will also be those that use complex UIs, but they'll lose out to the
>simple UIs over time); if we don't want to wind up with *different* subsets,
>non-interoperable ones, then we'd better pick a single subset *now*.
>
>John, it is looking like the RECUR rules are too complex. That issue keeps 
>"recurring".  While you are there as a group in Minn perhaps you can 
>recommend a subset that will work as a good starting base.  This will help 
>the IPTEL group as well as ours.  Thanks.