Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping the version

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Thu Mar 10 09:49:36 2005

+1.  Also, we can specify that in the case of a "true" infinite 
meeting, it is the responsibility of the initiating server to send out 
a "renewal" at the end of the one/five/hundred year period.

On Feb 14, 2005, at 11:42 AM, Elias Sinderson wrote:

> Curt Ellmann wrote:
>
>> I agree that one year is too short-- what is the problem with 
>> infinitely
>> recurring events?  There are plenty of examples of events that are
>> infinitely recurring-- holidays, anniversaries, and other 
>> celebrations.
>>
> I only suggested one year as a matter of conjecture - the limit could 
> be five years, or ten, for that matter, as long as there is a limit 
> which allows a /finite/ expansion of recurring events. Note that this 
> was in response to Doug Royers observation that "the only noticable 
> issue is infinate recurring entries." I will also note that the 
> cannonical examples provided for infinitely recurring events have been 
> all-day events, which do not suffer from the timezone issues that have 
> been identified. As per Dougs' suggestion, the inclusion of a property 
> which indicates that a METHOD:REFRESH should be done in the future 
> seems like a good idea; simply a way to say 'and so on' or 'sync again 
> later'. I cannot think of a situation where a client would need to get 
> the infinity of recurrences in a single sync and not be able to sync 
> again in the future. Further, regarding the question of the duration 
> placed as an upper bound, allowing any given implementation to set 
> its' own upper bound on recurrences rather than having it rigidly 
> declared in the specification would make it possible for devices with 
> limited profiles to play along as well.
>
> It may be useful to step back from this issue for a minute and try to 
> identify use cases that require scheduling of recurring events (or any 
> event), e.g., five years out. Neither Hotels nor airlines will allow 
> one to place reservations that far in advance. The most difficult 
> restaraunt to dine at in California (French Laundry) only takes 
> reservations several months (4?) out. Business meetings are never 
> arranged in this matter, and it only seems a matter of convenience to 
> say that this meeting will recur infinitely rather than specify an end 
> date several years away. As I mentioned before, even so called 
> 'infinitely recurring' weekly project meetings are (semi)regularly 
> rescheduled to accomodate attendees constraints and other recurring 
> meetings that are scheduled. If anyone can provide a use case which 
> requires an infinitely recurring event which is not an all day affair 
> (such as holidays, birthdays, anniversaries, etc.), please provide it. 
> Extra credit will be given if it isn't some freaky and contrived edge 
> case, but occurs frequently enough that it would be an honest 
> inconvenience to a user to schedule seperate events.
>
> Deprecating infinitely recurring events and placing a sensible upper 
> bound as suggested would allow recurring events to be represented as 
> either a RRULE or as a finite sequence of events, and would sidestep 
> the issues related to timezones that have been raised previously on 
> the list. It would seem that the benefits of this simplification 
> greatly outweigh the downside of rescheduling a meeting every couple 
> years (if it lasts that long) or similar. Further, if RRULEs become an 
> optional part of the specification, as has been suggested before, this 
> approach would allow interoperability where one system implements 
> RRULEs and the other doesn't, as there won't be a problem in an 
> infinite expansion of events.
>
>
> Cheers,
> Elias
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Michiel 
>> van
>> Leeuwen
>> Sent: Saturday, February 12, 2005 2:58 PM
>> To: [email-masked]
>> Subject: [Ietf-calsify] Re: Comments on radical simplification and 
>> bumping
>> the version
>>
>> Elias Sinderson wrote:
>>
>>> Would it be reasonable to deprecate infinitely recurring events and 
>>> place an upperbound of, say, one year on recurring entries?
>>
>> I think it isn't such a great idea, becasue one year is a magic 
>> number. Why one year, and not two years?
>>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>