Subject: [Ietf-calsify] Re: possible VALARM solution?

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Sep 7 23:22:38 2004

I like the idea of the "off switch" for alarms, especially since we
implement reminders that way internally... Perhaps this is an extension
we should adopt in the standard in the spirit of simplicity in the
flavor of interoperability.  But of course, clients should still be
smart when alarms are not explicitly disabled.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, September 07, 2004 6:09 PM
To: [email-masked]
Subject: [Ietf-calsify] Re: possible VALARM solution?

[email-masked] wrote:

> Right - but _adding_  objects/components/properties takes us away from

> our simplification goal, and simplification is being discussed to 
> improve interoperability.

Yes it adds. Interoperability is the other goal. And that is part of
this debate.

Its simply a standardized way to tag the data so that cross vendors can
tell tell that the CU already answered your questions.

If you get a PUBLISH with a VALARM, the user says don't set them.
Do you delete the alarm and store the object without the alarm?
Or do you somehow remember that the alarm is to be ignored?

Now you get an update to that PUBLISHed object (which still contains its
valarm) , the LOCATION is changed, do you ask again?

Or do you remember that you said no to the alarm? How? Does your way
work with another vendor?

If you deleted the valarm then the new update looks like a new alarm -
correct?
So you ask again and delete it again?

The CAP solution was to store the VALARM with a ENABLE=FALSE parameter
and not delete the valarm. Now you know that UID:123 VALARM is to be
ignored from any vendors CUA no matter how may updates are sent to the
same object.

This also solves the problem of unwanted action types
(PROCEDURE/AUDIO/...) alarms
from imported alarms that may be updated over time. The CUA can always
set PROCEDURE alarms to disabled in a way that other CUAs can tell.

Its not simple if its not interoperable.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Wed Sep 8 08:50:51 2004

Hi Cameron,

> smart when alarms are not explicitly disabled.

In my client I ended up implementing two private x-props to handle alarms 
(in particular repeating alarms and alarms on recurring events/to-dos). The 
two are:

1) A status property with three possible values:

   - 'PENDING' - means the alarm is active and the client needs to monitor 
it to see
                 when it is triggered, or whether it should have already 
been triggered
                 (i.e. client session was started after trigger time). 
Determing the next
                 trigger is based on the 'LAST-TRIGGER' property described 
below.

   - 'COMPLETED' - means the alarm has been signaled to the user and there 
is no need
                   for the client to monitor it further. This provides a 
useful shortcut
                   for the client as it means it can ignore the alarm 
altogether - no need
                   to determine trigger time etc

   - 'DISABLED' - means the user has explicitly disabled the alarm so the 
client does not
                  need to monitor it.

2) A 'LAST-TRIGGER' property with a date-time value. This indicates the 
last time the alarm was triggered and is used to track which triggers in a 
repeating alarm have already been signaled. This provides a smart way for 
the client to know whether it needs to signal an alarm that would have 
occurred prior to the current session.

'LAST-TRIGGER' is a necessity in my mind for handling repeating/recurring 
alarms. I think the status indicator is also required, as this thread has 
shown.

In addition I would also like to argue for a change in the VALARM component 
- specifically the ability to have a VALARM be a 'primary' component like 
VEVENT/VTODO etc - i.e. its not limited to being embedded inside another 
component. Part of the current problem with alarms for one user 'leaking 
out' to others is that the alarm data is embedded in the event so it gets 
transported with that event. By separating the alarm from the event, there 
is a clear distinction between the two and less chance of leakage of 
per-user alarm data. The other advantage is that it allows for the option 
to use a 'library' of standard alarm behaviours (e.g. 'five minutes 
before', '30 minutes before' etc) which can then be linked to the 
events(i.e. one alarm component can be used to trigger multiple alarms on 
different events). I suspect most people use pretty much the same type of 
alarm behaviours time after time so this would save on storage.

The big disadvantage to the separate alarm model is maintaining the correct 
links between the alarms and the events/to-dos. Ideally the links should 
only be in the alarm component, say by the use of a 'RELATED-TO' property 
containing the UID of the event/to-do that the alarm applies to (multiple 
'RELATED-TO's would be allowed to enable the alarm 'library' capability).

Obviously this is a significant change to iCal - but I think it would be 
worth it. Note that the current design of caldav actually does split alarms 
out into a separate webdav collection, though there is some debate about 
that. Also, CAP had to go through all kinds of twists in order to be able 
to handle per-user alarms on shared events etc with the current embedded 
alarm model.

-- 
Cyrus Daboo