Subject: Re: Max # of occurences in a recur rule?

From: [email-masked]
Date: Thu, 1 Jun 2000 22:04:48 -0400

Eric pondered:
>Can an
>implementation assume that there will be no more 366 occurences per
>interval and reject any rule that has more?[Snip]
>Implementing recurrence rules gets difficult when you have to handle the
>most general case, since some of these cases get excessive.

Id point out a MUCH simpler case than your very very nasty one: if the 
rule is simply FREQ=DAILY;BYHOUR=9,10 then you are automatically over over 
the limit after just 6 months of instances.  Then I realized that if the 
rule were just simply FREQ=DAILY;COUNT=400 then we've already blown the 
ability to use BYSETPOS for instances 367-400.  If you used negative 
values you could get to them simply make COUNT=800 and there is now a 
'hole' in the middle we cannot access by BYSETPOS.  The same can be said 
for infinite recurrences (ie: FREQ=DAILY;BYDAY=MO)...

So, I think that BYSETPOS probably needs to be expanded to allow for any 
values that that the rest of the recurrence rule can generate.  Do I want 
to be the one that does the rewrite of the prose and ABNF (MUST be precise 
w/that ABNF); no way!  I dont know of anyone using or supporting BYSETPOS 
yet (I havent played w/libical, just commercial stuff) so Im not too 
worried yet.

>Can an implementation reject a strictly conforming but logically
>insensible rrule?

A CUA can reject anything it likes (hopefully w/in reason; I wont reject 
GEO: even if I may not use it).  In the cases Ive seen so far, the CUAs 
simply ignore (w/o any indication) those properties or property values 
they do not like in things like RRULEs.  They SHOULD be sending back some 
REQUEST-STATUS that indicates to the Organizer "Hey, I didnt quite grok 
your RRULE" or "You generate bogus RRULEs" or some other such response 
status.  Thats why we allowed > 1 REQUEST-STATUS in a REPLY.

If your CUA can parse the iCalendar data then its in conformance w/the 
RFCs.  Thats not to say it must support every property otherwise we'd 
never get CalConnect 2.0 off the ground as we will all be busy writing for 
features we cannot or do not want to support.

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: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 16 Jun 2000 14:47:11 +0200

As I see it:

There is a point F at which the mechanism of 2445 recurrence fails.  This
point occurs somewhere on the continuum between sheer simplicity S (viz. a
meeting held two consecutive Fridays at 9am) and hair-pulling complexity C
(viz. an 18 month course and duty schedule for interns at a hospital).

<S......F.........................................C>

Attempting to publish with stock 2445 syntax anywhere past F is not
advisable, even if possible!

I suggest if we were to have access to the statistics over all iCal usage in
this world it would show that standing 2445 syntax affords at least 90/10
efficiency.

I suggest that complex scheduling past F craves its own sub-syntax if one is
to achieve efficiency.

I also suggest that persistent scheduling (such as the opening
times/operating times of businesses, services, and other resources) also
craves its own syntax and that there is a place for this within CALSCH
...but now I am re-occurring myself:-)

Greg

***News Flash***

SKiCal goes International!

The International newspaper chain "Metro" has chosen SKiCal as their
standard for event publishing for Newspapers in 16 cities in 12 countries!!!

http://www.ietf.org/internet-drafts/draft-many-ical-ski-02.txt

---

From: Bob Mahoney <[email-masked]>
Date: Fri, 16 Jun 2000 17:00:57 -0400

Greg-

Can you give an explicit example that illustrates the failures that 
you see occurring near or at "C"?

An example of the 2445 grammar failing, and maybe a suggested fix, 
might make this easier to discuss.

-Bob