Re: CAP-12-e: Alarms and SEQUENCE

<WARNING: This posting contains several historical references up front so 
may be a bit long before returning to the technical bits>

Doug replied on 10/20/2003 07:13:30 PM:
> Please read the archives (which you participated in), in summary:

Ok, that confirms that I did ask about it before.  Guess I never got an 
answer that made sense to me...  Searching for VALARM and SEQUENCE yeilds 
many matches so can you please reference the date of discussion or the 
subject of the thread where we actually resolved this? 

I see several cases of us discussing stuff under different topics but 
nothing specific where we discussed adding SEQUENCE to VALARMs.

I found a proposal from Roger Dox under the Subject "Adding more unique 
identifiers" dated 07/13/2001 05:43:33 PM AST that got 0 WG discussion 
(but he correctly proposed using UID). 

I found a thread from Bernard under the Subject "Modifying VALARM (Was: 
VCAR: CARID Property)" dated 01/14/2002 11:00:48 AM that said in part:

You lost me Doug.  This thread is about *VCAR* not VALARM.

If I'm not mistaken, you are re-opening the issue that
was closed at the end of November 2001.

http://www.imc.org/ietf-calendar/mail-archive/msg02442.html

to which Doug replied (in part):

Once a user changes the contents of a VALARM, the UID is BOGUS
and does NOT uniquely identify anything. At that point
you have two or more VALARMs with the same UID. Now UID
means unique-but-not-really. We would then BUST UID.

Now if that were true, making changes to any VEVENT or VTODO would also 
cause UID to "bust" and I think we all agree that isnt true. 

I found a subthread by Doug under the subject "Re: CAP Issues And To-Do 
List" dated 01/13/2002 10:55:12 AM MST that said in part:

- Add a UID to VALARMs. (December 2001.)

Add ALARMID or SEQUENCE to VALARMS. The idea is to uniquely
identify a VALARM within a component. There is no need for
it to be globally unique.

I found a subthread by Doug under the subject "(#1) synchronization part 
2, and identifying a components VALARM" dated 02/13/2002 10:32:51 PM MST 
that said in part:

     How do you identify which VALARM is being modified
     in a component when the CUA wishes to <modify> a VALARM
     in an existing component and that components contains two
     or more VALARMs. (See UID vs ALARMID debate.)

Only Mark at Steltor and John Strack even responded to the proposal.  Mark 
to correct an example and John to say he liked it so I doubt that this is 
the thread Doug was referring to.  It appears that between 13-Jan-2002 and 
13-Feb-2002 Doug had a change of heart on UID vs SEQUENCE but I can find 
no WG discussion or acceptance of this.

Even tough the threads above all discuss ALARMID vs UID, I can find no WG 
discussion of opting for SEQUENCE as an identifier except for Dougs 
proposal that we did not discuss.  It appears that after we changed 
editorship the change just happened or I cant find that thread.  Im sure 
Doug or his sidkick Mark will yell otherwise but instead of doing that why 
not just provide an archive citation to the contrary and save everyone the 
cycles.

In still trying to understand this need thats not clearly spelled out in 
the CAP draft I find the first reference to "ALARMID" in the archives is 
actually dated 04/02/2000 12:00:06 AM PST on Dougs "CALSCH Action Items" 
automated posting.  It is merely:

 The following are a list of action items for the iCalendar-2 draft:

 Draft Action Item  Who          Done (Y/N)
 -----------------  ---          ----------
...
 I-4 Add ALARMID to VALARM ?                                             Y

So I backtracked even further.  Waaay back on 07/10/2000 10:47:48 AM AST I 
actually questioned this item to which Doug kindly replied:

It was on the list or at an IETF meeting - I forget which.

ALARMID's are needed CAP because it would be impossible to
modify an alarm without being able to identify which of multiple
alarms in a component would be the target of the METHOD:MODIFY.

Well, it does NOT appear in any posted meeting minutes NOR does it appear 
in the WG postings prior to 04/02/2000 12:00:06 AM PST so I still question 
it.  MODIFY clearly describes how to identify a component to modify with:

   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.

The CUA is responsible for sending the old VALARM properties that uniquely 
identify the desired VALARM (among its peers, if any) just as it does for 
all other compontents.  This works the same for all components so _why_ do 
we need to change VALARMs??   Or are you suggesting that MODIFY works for 
all other component / subcomponent types except VALARMs?...

</WARNING: Here endeth the historical research section>

> Its to allow the CUA to uniquely identify any VALARM in
> any component. Read up on the MODIFY command debate.

Umm, SEQUENCE does not uniquely identify the VALARM the way its defined by 
iCalendar.  iCalendar defines SEQUENCE as:

   Purpose: This property defines the revision sequence number of the
   calendar component within a sequence of revisions.

so its clearly a revision tracking propery, not a identification type 
property like UID:

   Purpose: This property defines the persistent, globally unique
   identifier for the calendar component.

CAP appears to be reusing SEQUENCE incorrectly and _implicitly_ assuming 
that every VALARM will have one that never changes no matter how often or 
when the VALARM is changed.  Since a VALARM can repeat using iCalendar 
recurrence rules or dates, if you kept the current iCalendar specified 
behaviour for changing SEQUENCE on property changes like RRULEs or RDATEs 
then SEQUENCE would change on a VALARM which could make it NOT unique. Of 
course you could change the defined behaviour of SEQUENCE while you are at 
it but that is a totally separate discussion!

>    In addition a problem exists with the control of "VALARM" components
>    and their "TRIGGER" properties. A CU may wish to set their own alarm
>    (local alarms) on components. These local alarms are not to be
>    forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
>    and the "ENABLE" parameter. So for the protocol between a CUA and a
>    CS, the following changes apply to the CAP protocol from [iCAL]
>    section 4.6.6 page 67:
> 
> This was so you could add local VALARMs that are not to be
> forwarded. Read the debate on MODIFY and COUNTER where
> a CU wished to COUNTER an object and NOT have the VALARMs
> deleted or added that are local.

Local alarms are not relevant to this discussion.  I grok the need and use 
for local alarms vs ones an Organizer may send.  The line:

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

reads that neither local alarms NOR any SEQUENCE propery NOR any ENABLE 
parameter can be forwarded.  This implys that SEQUENCE is locally 
maintained by the CUA for its own purpose.  The stated intent was to 
uniquely identify the VALARMs but thats not how SEQUENCE is defined in 
iCalendar; that is how UID is defined though.  So if anything, the 
property to add would be UID (or ALARMID as previously mentioned).

> We have already had this debate. I see no new information in your post.

Too bad you didnt provide the citation to the previous discussion on this 
to save some time avoiding rehashing any old concepts...  Providing it 
would save us time and thrashing.

Since Doug is reluctant to provide a reference that he appears to have 
found Ill ask again:

_Why_ does the CUA need to have this identification mechanism for VALARMs 
since they do not exist outside other uniquely identified components nor 
are they sent alone via iTIP? 

If its for modification, the MODIFY command already provides text on how 
to do this for _any_ component type so I fail to see the need to 
(incorrectly) tweak VALARMs.  If its for some other need, Id like to know 
what it is so we dont make unnecesary changes to iCalendar. 

Anyone?  If there is a demonstratable need for adding an identifer to 
VALARMs then ok but if not, Im against adding it.  So far I have seen no 
demonstratable need...

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