CAP-12-e: Alarms and SEQUENCE

Ok, I thought I asked about this before but maybe not.  In CAP we added 
the SEQUENCE property to VALARMs:

     alarmc     = "BEGIN" ":" "VALARM" CRLF
                        alarm-seq
                  other-props
                        (audioprop / dispprop / emailprop / procprop)
                        "END" ":" "VALARM" CRLF

    alarm-seq   = "SEQUENCE" alarmseqparams ":" posint0 CRLF
...
   The CUA adds a "SEQUENCE" property to each "VALARM" component as it
   books the component. This property along with the "LOCAL" and
   "ENABLE" parameters allow the CUA to uniquely identify any VALARM in
   any component. The CUA should remove those before forwarding to non
   CAP aware CUAs.

Ok, I have a few comments/questions about this text/concept:

1: First off, since VALARMs are embedded in other components, what use is 
adding SEQUENCE to any VALARM on any particular component?  The workflow 
is done on the components the VALARM is embedded in, NOT on any separate 
VALARM so I see no benefit to tracking separate changes to the VALARM 
using SEQUENCE (what SEQUENCE is defined for).  It appears that SEQUENCE 
(and LOCAL and ENABLE) are local to a specific copy of the VALARM which is 
in turn specific to the component that it appears in.  Are we adding this 
to VALARMs solely to make it easier to find/change the VALARMs instead of 
using the mechanism already defined under Section 10.9 MODIFY Command that 
we use for all other components/subcomponents?

2: The SEQUENCE property is NOT a unique identifier type property so its a 
bad idea to use it to as such ("to uniquely identify any VALARM in any 
component."); its intended to track modifications or changes.  If you want 
to perform an identification role then you should be using UID or some 
variant of that property instead.  Again though I wonder if this is truely 
necessary to add to iCalendar.

3: Just how is a CUA to know if the recipient is a "to non CAP aware CUA"? 
 Aren't all CAP clients CAP aware?  Is the last line referring to things 
like sending over iMIP (or some other iTIP binding other than CAP) or am I 
missing something?

The text in Section 2. Additions to iCalendar that says:

                          These local alarms are not to be
   forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
   and the "ENABLE" parameter.

makes me wonder why an invitee would put a SEQUENCE on a VALARM they may 
have recieved from someone else (since it cannot be sent by the Organizer 
to any invitee per the text in CAP).  If the recipient accepted the VALARM 
(by accepting the containing VEVENT for example) then I see no need for 
the SEQUENCE property to be added to it.  All workflow happens at the 
VEVENT level and all changes still result in just 1 copy of the VEVENT in 
the calendar, what good is tracking changes to the VALARM subcomponent? 

If the sole reason is to be able to find it for modification, MODIFY 
already covers how to do this:

   The old-values is a component and the contents of that component are
   going to change and may contain information that helps uniquely
   identify the original component (SEQUENCE in the example below). 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.

so if the CU wanted to change a particular VALARM, the CUA simply sends 
back the info to identify which VALARM the CU changed and then the new 
info.  If its good enough for all other components/subcomponents it should 
be good enough for alarms.

Unless a clear and compelling reason for adding SEQUENCE to VALARM can be 
shown and documented in CAP I propose we remove this change to iCalendar 
from CAP 1.0.

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...