Subject: Interpretation of VALARM TRIGGERs in recurring components

From: "Graham Gilmore" <[email-masked]>
Date: Tue, 17 Apr 2001 18:00:56 -0400

I'm looking at the information given in RFC 2445 about the TRIGGER
property of a VALARM component (section 4.8.6.3).  While the default
value type of the property is DURATION, a DATE-TIME value type can also
be specified by means of a VALUE parameter.  I'm wondering what the
interpretation of this would be in the case of a VEVENT or VTODO that
has a recurrence rule:

    a) A single alarm is triggered at the given DATE-TIME for all
instances of the recurrence

    b) One alarm is triggered for every instance of the recurrence, at
the given DATE-TIME, i.e. multiple alarms at the same time (how would
this work for infinite recurrences?)

    c) The offset between the given DATE-TIME and the DTSTART of the
first instance is calculated as a duration (in hours/minutes/seconds),
and the duration is used to determine when each alarm is triggered for
each recurrence.  (The duration between an alarm trigger and its
recurrence instance would remain constant, even across DST changes.)

    d) Almost like (c), except the duration is not constant across DST
changes.  I can't even figure out how to express this one properly in
words, so I'm not sure how useful or straightforward it could be as an
interpretation :)

    I would lean towards (c), but it's certainly not as clear as it
could be.  Any other opinions or interpretations?

    Graham

---

From: John Stracke <[email-masked]>
Date: Wed, 18 Apr 2001 10:32:18 -0400

Graham Gilmore wrote:

> I'm wondering what the

I think the only interpretation that meshes with 2445 is (a), a single
alarm at a given time that has nothing to do with the recurrence.  Your
(c) (infer a duration given a date-time) is counter to the text ("The
'TRIGGER' property value type can alternatively be set to an absolute
calendar date and time of day value") in two ways.  First, the text says
"an", which implies exactly one.  Second, the text says "absolute", which
is counter to your inferred-duration approach.

Your (b) (one alarm per instance, but all at the same time) is, as you
say, not workable.

Granted, an absolute-time alarm in a recurring event is *strange*; but
it's not utterly useless.  Maybe I've got a procedural alarm that needs to
go off sometime before the first email alarm, but doesn't need to go off
on every one.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Illiterate? Write today for free help!       |
[email-masked]|                                             |
\==============================================================/

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 18 Apr 2001 12:22:45 -0400

----- Original Message -----
From: "John Stracke" <[email-masked]>
To: <[email-masked]>
Sent: 18 April, 2001 10:32
Subject: Re: Interpretation of VALARM TRIGGERs in recurring components

> is counter to your inferred-duration approach.

    The text refers to the value of the property, not the interpretation
of that value.  It's fairly straightforward on reading the text that
there be only a single property value, and that value be an 'absolute
calendar date and time of day value'.  It's the interpretation of the
value that I'm wondering about :)  I would agree that (a) seems to be
the simplest interpretation, but somehow it doesn't feel like that would
be the intent of someone who would include it in an iCalendar, if they
were working only from the RFC.
    Perhaps the (c) option I detailed would be reading too much into it.
In any case, as long as there's a single interpretation that's generally
agreed upon, I don't care all that much which one it is, as long as it's
not overly complex.  The real problem is that the text isn't clear on
what the meaning of the DATE-TIME form is, in combination with
recurrence rules.

    Graham

---

From: John Stracke <[email-masked]>
Date: Thu, 19 Apr 2001 11:18:29 -0400

Graham Gilmore wrote:

> of that value.

Since RFC-2445 doesn't specify an interpretation, we have to take the
obvious one: an "absolute calendar date and time of day value" implies an
absolute calendar date and time of day.  There'd be no point in supporting
DATE-TIME if it gives you the same semantics as DURATION.

|eCal Corp.      |Piscatorice non aristotelice.                |