Re: CAP-12-e: Alarms and SEQUENCE

Doug wrote on 10/21/2003 03:02:57 PM:
> Yes you do seem to understand why removing SEQUENCE breaks MODIFY
> of VALARMS. So I too do not want to break MODIFY of VALARMS.

Actually thats not what I said but Ive already pointed that out.   In the 
interest of resovling this quicker I took time to go reread CAP-12-e, 
Section 10.9 MODIFY Command again to see if I had just missed something 
originally.  After doing this I find that I still disagree with Dougs 
assertion that removing SEQUENCE from VALARMs breaks MODIFY. 

Lets take a look at the text and example to see why it does not break 
MODIFY.  First off, the command says (in part):

   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 a CUA does _not_ need to have an identifier for VALARMs, it merely 
needs to send back a VALARM fragment that "contain[s] information that 
helps uniquely identify".  That is, if there are multiple VALARMs such as 
1 ACTION:DISPLAY and 1 ACTION:AUDIO then the CUA merely needs to send back 
the correct ACTION property and value to identify which alarm is being 
modified.  If there is just 1 VALARM, any VALARM fragment should match 
uniquely.

If you look at the example used, it is attempting to disable a VALARM on a 
particular VEVENT.  The text currently states:

   Because "SEQUENCE" property is used to locate the "VALARM" component
   in this example,  both the old-values and the new-values contain the
   "SEQUENCE" property with a value of "3" and if the "SEQUENCE"
   property were to be left out of new-values, it would have been
   deleted.

However I contend that the use of SEQUENCE is unnecessary since its not 
changing nor is it necessary to identify the VALARM.  The other VALARM 
properties in the example are equially sufficient to identify the VALARM 
without requiring the CUA to send SEQUENCE in both the old and new data 
blocks just to avoid deleting it.  This MODIFY example can function 
equally well:

     C: Content-Type: text/calendar
     C:
     C: BEGIN:VCALENDAR
     C: VERSION:2.0
     C: PRODID:-//someone's prodid
     C: TARGET:my-cal
     C: CMD:ID=unique-mod:MODIFY
     C: BEGIN:VQUERY                   <- Query to select data set.
     C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
     C: END:VQUERY
     C: BEGIN:VEVENT                   <- Start of old data.
     C: LOCATION:building 3
     C: LAST-MODIFIED:20020101T123456Z
     C: X-LOCAL:some private stuff
     C: BEGIN:VALARM
     C: TRIGGER;RELATED=END:PT5M
     C: END:VALARM
     C: END:VEVENT                     <- End of old data.
     C: BEGIN:VEVENT                   <- Start of new data.
     C: LOCATION:building 4
     C: LAST-MODIFIED:20020202T010203Z
     C: COMMENT:Ignore global trigger.
     C: BEGIN:VALARM
     C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M
     C: END:VALARM
     C: END:VEVENT                     <- End of new data.

for the single VALARM case and equally well for the multiple VALARM case 
where the TRIGGER value is unique per each VALARM.  For the multiple 
VALARM case where TRIGGER (or whatever property is being modified) is not 
unique, you can use other properties like ACTION exactly the same way that 
SEQUENCE is currently used to correctly identify the VALARM in question.

Another reason is that for other components (ie: VEVENTs, etc.) we do NOT 
use a unique identifier (ie: UID) as part of the old-data & new-data 
blocks when trying to indicate them for modification so there is no need 
to do so for VALARMs.  The way the CS matches properties in the components 
works and Ive seen nothing to indicate that it would not work for 
subcomponents like VALARMs.

Finally, the insistance that SEQUENCE be used to uniquely identify the 
VALARM implicitly says the use of old-data contents to match particular 
properties to change does not work when in fact it does.  If I were to 
accept the "you need to have an identifier property for every component / 
sub-component you want to modify" argument then we would need to put some 
form of identifier into ALL components and subcomponents. 

For example to modify a particular VDAYLIGHT inside a given VTIMEZONE, you 
would have to have a unique identifer for every VDAYLIGHT inside the 
uniquely identified VTIMEZONE. 

For any X- type components / subcomponents, there would have to be some 
unique identifer as well but the CS will have no way of knowing exactly 
what is the 'unique identifier' property and which is just an experimental 
property thats being modified.  The same goes for any IANA-components 
going forwards, you have no way to in advance know what the unique 
identifier property is going to be. 

So, since its not actually necssary to put an identifier on a VALARM to 
correctly find it for modification I again have to contest the need for 
this change to iCalendar.  The _exact_ same result (modifying the correct 
VALARM) does not require adding SEQUENCE (or ALARMID as previously 
decided) to VALARM, it can simply and easily be done using the existing 
properties in the VALARM.

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