Subject: VALARM: UID VS ALARMID [Was: Re: (ALARMREF?) ALARMID to VALARM after stored?]

From: George Babics <[email-masked]>
Date: Mon, 11 Feb 2002 13:23:52 -0500

This was brought up a few times. We should
resolve it once and for all.

CAP added a property to VALARM called "ALARMID."
Its value is unique within the scope of the
event, todo, or journal that it is found in.
It allows one to uniquely identify a VALARM
within a component.

A suggestion was made to use UID instead of
ALARMID. UIDs are globally unique, thus one
can have global VALARMs in a future version
of CAP, if this feature is ever needed.
Furthermore, we reuse a property and do not
have to defined a new one.

Thus I await you opinions. ALARMID or UID?

George

George Babics wrote:
> 
>   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
> 
> Doug Royer wrote:
> >
> > Bernard Desruisseaux wrote:
> >
> > >
> > > 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?
> >
> > 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.
> >
> > > 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.
> >
> > 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: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 14:07:35 -0700

> Thus I await you opinions. ALARMID or UID?

I prefer ALARMID.

I will be sending out in a day or so the 'LOCAL ONLY' proposal.
If that or an idea like that goes, then I could go with UID.
But if we don't somehow agree to mark the VALARMs as local,
then there would be NO way to separate out who's VALARM+UID
should be forwarded to delagated-to UPNs or which ones
belong to the ORGANIZER and would be sent in COUNTER messages,
and other such problems.