Re: Alarms/SEQUENCE (was Re: Status of the CALSCH working group)

Mark replied on 11/09/2003 03:57:53 PM:
> On my PDA the default entry is audio alarm. I have often accidentally
> created two audio alarms when I really wanted one audio and one pager
> (email) alarm. Then had to go back and fix them later when the
> two alarms go off which when I notice that I made the mistake.
> 
> If CAP did not allow me to fixed them I have to throw away
> the entire VEVENT and start over? I hope not.

Unless they are exactly the same then identifying the one you want to 
remove is trivial.  Also, if VALARMs were treated like VEVENTs:

   There MUST NOT BE more than one "BOOKED" state object in a calendar
   for the same "UID".

and later:

                                                    If a duplicate
   [iTIP] object is deposited into the CS and there exists identical
   marked for delete objects, then a CUA acting on behalf of the "OWNER"
   can silently drop those duplicate entries.

then you'd never have this problem since the duplicate AUDIO alarm would 
not be created to begin with.  Im assuming its duplicate even though you 
did not actually say this.

> VALARMS need a unique identifier. Think about it, the topic is
> why would you need to uniquely identify a VALARM in a MODIFY command.
> One answer is to fix a problem.

The ONLY reason a VALARM would need to have a unique identifier is if we 
allowed exact duplicate VALARMs (a questionable decision given the other 
prohibitions in iCalendar and CAP and the usage scenarios for it).  I have 
already shown that the MODIFY command does NOT need to include any 
identifier in order to modify a particular VALARM; the CUA simply needs to 
send enough VALARM properties to uniquely identify the VALARM in question.

If we do decide that we want to allow duplicate VALARMs per component then 
more questions arise.  Other related questions related to addition to 
iCalendar include:

1: If there is no ALARMID / SEQUENCE property on a VALARM, does the CUA 
need to assign one?  An example of this is an entry that is created 
outside of CAP and delivered to the CU.

2: If the ALARMID / SEQUENCE property can be locally assigned for entries 
that originate elsewhere then are they preserved when the entry is sent to 
someone else (ie: The CU delegates the VEVENT)? 

3: Just how is the fact that the VALARM is NOT "local" to the CU (ie: it 
came with the REQUEST) but the ALARMID / SEQUENCE value IS "local" 
tracked?  Do we now have to add a new property parameter to ALARMID / 
SEQUENCE to track this too?

4: If exact duplicate VALARMs are 'legal' then how do we resolve the case 
where the sender included multiple exact duplicates with no ALARMID / 
SEQUENCE?  There is no way to initially distinguish between the two so a 
MODIFY command MUST fail by:

                                                                  If
   the CS can not find a component that matches the QUERY and does not
   have at least all of the OLD-VALUES, then a 6.1 error is returned.

because there was no unique match on all the old-values.  Catch-22.  The 
simpler solution is to prohibit exact duplicate VALARMs on any particular 
component and all the problems or questions can go away.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...