Subject: CAP-12-e: Alarms and SEQUENCE

From: [email-masked]
Date: Mon, 20 Oct 2003 17:27:42 -0400

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 20 Oct 2003 17:01:16 -0600

[email-masked] wrote:
> 
> Ok, I thought I asked about this before but maybe not.  In CAP we
> added the SEQUENCE property to VALARMs:

So you say you do not understand, yet you quote text from CAP that
answers your questions. Then in the next question you address the
issue you just raised.

I renew my belief that you are doing you best to stall CAP
from being released. Your selective reading of CAP causes
your underinformed or misinformed posts to cause debates that
are not needed. Just searching for the word SEQUENCE I found
several hits, including:

   A CUA may add the "LOCAL" parameter to the "SEQUENCE" property before
   booking the component. If the "LOCAL" parameter is set to "TRUE",
   then the alarm MUST NOT be forwarded to any other calender. If set to
   "FALSE", or if the "LOCAL" parameter is not in the "SEQUENCE"
   property, the alarm is global.

and

   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:

and

and

   SEQUENCE -  When the "SEQUENCE" property is used in a "VALARM"
   component it uniquely identifies the instances of the "VALARM"
   within that component.

and

and

   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.

and

   2.  If a contained component is changed inside of a selected
       component, and that contained component has multiple instances,
       then old-values MUST contain information that uniquely identifies
       the instance or instances that are changing. It is valid to
       change more than one. As all contained components that match
       old-values will be modified. In the first modify example above,
       if "SEQUENCE" properties were to be deleted from both the
       old-values and new-values, then all "TRIGGER" properties that
       matched the old-values in all "VALARM" components in the selected
       "VEVENT" components would be disabled.

---

From: Doug Royer <[email-masked]>
Date: Mon, 20 Oct 2003 17:13:30 -0600

[email-masked] wrote:

> 1: First off, since VALARMs are embedded in other components, what use 
> is adding SEQUENCE to any VALARM on any particular component? 

Please read the archives (which you participated in), in summary:

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

CAP also says:

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.

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

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

-- 

 Doug Royer                     |   http://INET-Consulting.com 
 -------------------------------|-----------------------------
 [email-masked]                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards

---

From: [email-masked]
Date: Tue, 21 Oct 2003 10:24:23 -0400

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

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

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

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

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Oct 2003 11:53:29 -0600

[email-masked] wrote:

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

Why do you continue to blame others? Why do you not ask the chairs?
Do they not track consensus?

I for one do not want sequence to change. It seems obvious that
it is used to uniquely track valarms in components. Even your
own original post quoted that. And you posted no solution
to the problems that your own email said sequence solved.

I say please do not change it, cap (other than some typos that
I found and rewording that others have requested) is technically
ready.

---

From: Doug Royer <[email-masked]>
Date: Tue, 21 Oct 2003 13:02:57 -0600

[email-masked] wrote:

>
> <WARNING: This posting contains several historical references up front 
> so may be a bit long before returning to the technical bits>
>
> 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?  
>          

The archive is several megabytes in size. No I will not be posting it so 
that every thing
is in context. That is why there is an archive on line.

Yes you do seem to understand why removing SEQUENCE breaks MODIFY
of VALARMS. So I too do not want to break MODIFY of VALARMS.

--

---

From: [email-masked]
Date: Wed, 22 Oct 2003 14:02:53 -0400

> is in context. That is why there is an archive on line.

A simple citation with post, subject or date are sufficient.  I found some 
going back as far as 2000 but I found NOTHING in the archives to support 
the _need_ for the change.

> of VALARMS. So I too do not want to break MODIFY of VALARMS.

Umm, no.  Given the text of MODIFY I see no demonstratable need to have a 
unique identifer on each alarm inside any component that already has a 
unique identifer.  MODIFY already says how to uniquely identify the bits 
to be changed (ie the VALARM) so _why_ do we need to misuse SEQUENCE?

Despite your previous assertions I did manage to find mention of ids on 
alarms dating back to 2000: I can find NO evidence of IETF meeting 
discussion of the need prior to you listing it as an issue starting ~April 
2000 nor any WG mention (let alone discussion of it) until ~Nov 2001, 
nearly a year and a half after it first appeared on your CAP issues list. 
We did discuss using UID vs ALARMID (or ALARM-ID to some) in late 2001/ 
early 2002 and then you magically changed it to SEQUENCE ~Feb 2002. 

However I think that we have no _demonstratable_need_ to modify VALARMs to 
have unique identifiers.  Or as you put it back on 07/10/2000:

The MODIFY command is pretty clear on dealing with identification of data 
to be changed (see previous msg) so I again have to ask why we need to 
mis-reuse SEQUENCE by adding it to VALARMs?  (The change from the WG 
agreed on UID is a different question...)

Can you _please_ provide a simple example of a MODIFY command that needs 
to have SEQUENCE on the VALARM in order to work correctly??  Perhaps the 
ever enthusiastic Mark can do this for you if you are too busy...

I think the MODIFY command does not need this change to VALARMs.  If it 
really does not then Im against making the change to iCalendar.  However 
if its there for non-demonstratable reasons then it should not be made to 
iCalendar.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Oct 2003 12:53:09 -0600

[email-masked] wrote:

> Umm, no.  Given the text of MODIFY I see no demonstratable need to
> have a unique identifer on each alarm inside any component that
> already has a unique identifer.  MODIFY already says how to uniquely
> identify the bits to be changed (ie the VALARM) so _why_ do we need to
> misuse SEQUENCE?

You still propse to break MODIFY wihout any solution. No one
wants to break modify.

I do not know which version if any draft or published text you
have been reading, but I can not find ANY other unique identifier
for VALARMS. What is it?

---

From: [email-masked]
Date: Fri, 31 Oct 2003 13:42:07 -0500

> 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):

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:

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 31 Oct 2003 15:16:09 -0700

[email-masked] wrote:

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

Better yet, an example of when MODIFY breaks.

Take TWO VLARMS that are identical in one component.
Withou a unique identifier  - you can not uniquly identify  the 2nd 
instance.
Now show me an example where you can without a unique identifier
replace the ACTION in the secoond valarm and make it antother value.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044