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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...