[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Repeating alarm specification
I, for one, think that using RRULE for alarm specification is total overkill.
Who is going to write a user interface for users to specify an RRULE for alarm
times? The way it is now provides (IMHO) plenty of options for repeating the
alarms. If we were to allow RRULE to specify this we would end up with so many
varying levels of support for this complicated property that interoperability
would be hindered. Lets keep this simple!
Lets stay focused on the task at hand which is... Getting this already well
thought out specification to RFC status. Last call is too late to be thinking
about changes like this.
On Thursday, March 26, 1998 5:31 PM, David A. Curley
> If I understand this correctly, the "DURATION" and "REPEAT"
> properties specify how often and after what delay an alarm
> should be repeatedly triggered.
> Why is there a private scheme for defining recurring events
> in the alarm case, when we have a perfectly good, and much
> more flexible, language for doing exactly this for the other
> calendar components ?
> These two properties should be replaced by a single. optional
> property, RRULE, with a value type of RECURR. When present
> it defines the repeat pattern for the alarm. When absent,
> the alarm triggers just once.
> Comments ?