Subject: Re: Another recurrence ambiguity

From: [email-masked]
Date: Mon, 27 Nov 2000 13:34:57 -0500

John replied with:
>Of course, if you do get an event with an inconsistent RRULE,
>then the meaning is obvious: the set of recurrences is empty
>(it's the intersection of two disjoint sets)

Well, the RFC never talks about intersecting anything and it never 
expressly precludes non-sensical rules like the one I gave (an oversight 
we will fix).  We (Eric) were going to clarify the recurrence rule text so 
that it expressly describes evaluating the BYxxx parts (not JUST their 
order of evaluation) and put some text that precludes mixing and matching 
of values that can be 'disjoint'.  Since you have a concept of 
intersecting data sets perhaps you can give Eric some text to include.

I do agree that most CUAs will ignore the RRULE (and send the proper 
REQUEST-STATUS to indicate this I _hope_!!) but not all CUAs agree on when 
to do this.  Some of the less robust engines may treat bogus rules the 
same as ones they 'dont quite handle' even though they are different 
causes.

Im sure the various ideas will come to light at the next CalConnect but 
given the time till then and the traffic it will generate afterwards I 
think we can start codifying a more generally accepted understanding 
before then to progress the work along now.  Dont you?

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: Eric Busboom <[email-masked]>
Date: Mon, 27 Nov 2000 11:47:51 -0800 (PST)

> that it expressly describes evaluating the BYxxx parts (not JUST their 

The text I proposed is at: 

	http://www.imc.org/ietf-calendar/mail-archive/msg04779.html
 
( Comments Please! This is an outstanding issue that has not reached
consensus. ) 

The proposed text would not cover this current issue, though. 

> same as ones they 'dont quite handle' even though they are different 

I think this is the primary problem with the current RRULE spec. There are
no details for handling these invalid cases, so the only CUAs that will
ignore the rule are those whose designers caught the discrepancy. This
means that there is no hope of interoperability on these fringe cases.

So, if we are going to fix this, you ( yes, you, Damon, John and Bruce
) need to review the proposed text referenced above or propose some text
of your own. 

For the current issue, "FREQ=WEEKLY;BYDAY=2TU" can we declare it to be
invalid? How about something like 

  For FREQ=WEEKLY, BYDAY rule parts MUST have
  integer values of 1, or the interger value MUST be omitted.
  "FREQ=WEEKLY;BYDAY=TU" is valid, but "FREQ=WEEKLY;BYDAY=2TU" is not.

eric.