I hope these posting are not being lost in the overwhelming slience on the list the past couple of days. :^)hey! I'm reading it.
Actually, while getting down and dirty with some vEvent or vToDo restriction tables I found what could be an oversight in our restriction tables. In 3.2.2 REQUEST (and other 3.2.x and 3.4.x subsections) the restriction tables in part read:Jeez, how do you dream this stuff up ? :-) Sounds reasonable though. In fact, totally independent of iTIP, this sounds like a sanity check on the makeup of a repeating component. Is this something that should go in iCalendar?DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
and
RDATE 0+
and
RRULE 0+Now if you are the cautious type you may see what could be restriction table oddity: it is possible to have a vEvent / vToDo that has NO DTEND/DUE or DURATION value but does have an RDATE / RRULE. If the first entry enver ends (at least for vEvents) then how can it repeat since the initial instance cannot complete? One can assume that 'overlapping' entries are allowed depending on how you view repeating entries but I dont know of any C&S system that allows open ended entries that can potentially repeat infinitely (ie: RRULE w/no COUNT or UNTIL).
Since we are looking at cleaning up iTIP (and in the interest of KISS) I would like to suggest that we ammend the tables to preclude an entry from repeating if it does NOT have a finite length or end/due date & time. Any disagreement?
-Steve
begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@xxxxxxxxxxxx title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard