Subject: Re: ALARMID to VALARM after stored?

From: "John Stracke" <[email-masked]>
Date: Wed, 21 Nov 2001 10:57:34 -0500

>VAGENDA was introduced in September 

That would be it--I was between jobs at the time, and not on the list.

>CUAs already have to deal with stored VQUERYs and VTIMEZONEs as
>top level components, I don't see why they would be confused
>with VALARMs as top level components.

These three cases are nonparallel.

Stored VQUERYs are purely a CAP matter; they involve no change to 
iCalendar.  (They could be implemented via ACAP, but putting them into CAP 
makes it possible for an implementor to optimize them--something you might 
prefer not to do for on-the-fly queries.)

VTIMEZONEs are contained within the same component that contains the 
VEVENT; modifying one's iCalendar code to cope with that container being a 
VAGENDA instead of a VCALENDAR is minor.

Top-level VALARMs, though, are *not* a minor change.  You're moving from 
searching for a VALARM within the VEVENT to searching within the VEVENT's 
container.  Your VEVENT cannot then be passed to a non-CAP implementation 
(say, via iMIP) without transforming it.

More fundamentally, the alleged convenience of storing one's "preferred 
alarm properties" as VALARMs, and then using those VALARMs by reference, 
is a Bad Thing.  What happens when I change my preferences? Suddenly, all 
my VEVENTs that used the default VALARM are changed.  That's surprising. 
Usable designs strive to *avoid* surprise.  A properly designed CUA would 
have the preferred alarm settings stored as normal preferences (either 
client-side or via ACAP), and create a VALARM with a *copy* of those 
preferences for each new VEVENT.

(One might argue that the user might sometimes want to change all the 
default-settings alarms at once.  I suppose that's theoretically possible; 
but I believe it would be rare--I know I've never wanted to on any of my 
calendars.  If necessary, it can be done by, well, changing all the 
alarms: the CUA issues a VQUERY to find all VALARMs that match the default 
settings, then changes them.)

/================================================================\
|John Stracke                   |Principal Engineer              |
[email-masked]  |Incentive Systems, Inc.         |
|http://www.incentivesystems.com|My opinions are my own.         |
|================================================================|
|"The struggle is always worthwhile, if the end be worthwhile and|
|the means honorable; foreknowledge of defeat is not sufficient  |
|reason to withdraw from the contest." -- Adron e'Kieron, by     |
|Steven Brust                                                    |
\================================================================/

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 22 Nov 2001 17:48:05 -0500

> (say, via iMIP) without transforming it.

The required transformation would be pretty straightforward.
Really minor compared to the required conversion of CAP calendar
addresses to mailto URLs.  Furthermore, in most cases you should
probably not send the VALARM to the other attendees.  What's the
point of sending your VALARM to other people?

> preferences for each new VEVENT.

A CUA could easily remind the CU about the impact of changing a
VALARM referenced by other VALARMs before sending the "modify"
command to the CAP server.

Personally, I would be more concerned about the consequences of
modifying a VCAR referenced by other VCARs, or a VTIMEZONE on
which multiple VEVENTs may depend.

> settings, then changes them.)

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Recherche et développement              Tél.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 Nov 2001 13:32:36 -0700

> point of sending your VALARM to other people?

Maybe they want it?  Maybe it is not a person, but a program
that is doing work for you and the action in the alarm is
a program to run? Maybe the real need for the request is
to synchronize or copy a calendar? I think the point is that
they can send VALARMs, and you can get VALARMs. So John's point
is valid - if we do this - there must be an iTIP transformation
process when sending/getting iTIP messages.

iTIP does not handle them, so any iTIP messages sent would
have to include them and not reference them. But the same
is true for VCARs and VTIMEZONEs. We can't break RFC2446, so
there MUST BE a transformation. 

> which multiple VEVENTs may depend.

Time zones do change and thus any good implementation MUST NOT
think they are static. The same is true of a VCAR, they
are not static. And a CUA can change any VALARM already.

The only real change is do we allow VALARMs outside of a VEVENT
or VTODO?  If yes, then we MUST specify rules for modification.
Do we say that if a CUA modifies a VALARM that is common to
more than one VEVENT do we:

	1) MODIFY the one global and warn the user?

	2) Replace the VALARM in the component with the global VALARM.
	   Remove the ALARMREF in the copy.
           Then modify the copy in that target component?

        3) Add a parameter that says 'target components only' or 'all'.
           Then apply rule (2).

        4) Not allow global VALARMs?

I would lean to (4) in CAP, just to get it out the door. However
if the WG wants global VALARMs - I would not object.

-Doug

---

From: George Babics <[email-masked]>
Date: Wed, 28 Nov 2001 09:17:45 -0500

This is what we can do:

  1) Not allow global VALARMs

  2) Replace ALARMID by UID. It will be one less property to
     define. Furthermore, if in a future version of CAP we will
     want to have global VALARMs, they will be easier to add.

  Everyone agree? If not, speak up now!

George