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

Greg replied on 11/10/2003 07:58:43 PM:
> 1) To move CAP along, I think we have to concede that the question of
> unique ids for VALARMs was already considered, and unique ids were
> considered good by almost everyone.  From the archive, it appears this
> was most heavily discussed November 2001-January 2002, and everyone
> seemed to agree that alarmids of some sort were useful.  For example, 
from:
> 
> <http://www.imc.org/ietf-calendar/mail-archive/msg02317.html>

While we did discuss its addition back then, we did not cover all the 
bases (nor was the actual need discussed that I can see but thats a 
different topic).  Undiscussed or answered bits that come to mind are:

1: The addition is NOT optional (see ABNF) so if someone creates a VEVENT 
with a VALARM without SEQUENCE (aka ALARMID) then its considered an 
illegal VALARM.  This means that any iTIP gatewayd content without the 
required property is considered 'invalid'.  This is not goodness.

2: CAP says:

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

That is, when someone sends a VEVENT with a VALARM on it, local alarms and 
the SEQUENCE and ENABLE bits are NOT sent.  This is in direct conflict 
w/the ABNF of '1' which is what was previously decided on in that 
discussion you found:

> I think we should declare that this is a '1' and not
> a '0 or 1'. [Snip, snip]

I agree. 

which would say tthat any and all VALARMs MUST have an identifier added no 
matter what.  It seems the intent was to coerce CUAs into creating 
SEQUENCE (ALARMID) for those entries they are dealing with locally BUT it 
is NOT to be sent on the wire to others (at least thats how I read the CAP 
text above).  If thats the case then the ABNF for this change MUST be '0' 
or '1', not '1' since the invites, reschedules, etc sent would have to 
strip off the new stuff (or the local stuff).  Otherwise those items sent 
would have to have SEQUENCE (ALARMID) on them (to conform to the ABNF) and 
thats contrary to the current text (and I suspect the intent from that 
early work).

3: If we opt to make the SEQUENCE (ALARMID) property truely a '1' in the 
ABNF then some adjustments will need to happen to allow for legacy data 
that does NOT contain it.  That is, if an invitation arrives via iMIP then 
in order for it to be put into the CS someone has to coerce the missing 
property onto it.  However, is this identifier on alarms truely necessary 
when the entry is NOT "BOOKED"?  I suspect not but Im open to discussion 
otherwise.   (After all, whom ever assigned that new property value was 
NOT the Organzier so it should be considered a local change and thus not 
propigated to others.)

4: If we say that SEQUENCE (ALARMID) is to be used on all VALARMs in CAP, 
BOOKED or not, then we need to invent a new property parameter for 
SEQUENCE (ALARMID) to indicate if the property was created locally for 
legacy data or not and the property should not be propigated further.  For 
example, if an iTIP invitation arrives without a SEQUENCE (ALARMID) 
property on it, the recipient is mandated to create one.  However since it 
was locally created and not assigned by the Organzier it should not be 
propigated on a delegation notice that the CUA creates.  Otherwise it 
violates the iTIP text on delegation since the delegation info has been 
modified from its original info (beyond what iTIP says to do for 
delegation tracking).

Before we can move on, these undiscussed issues need to be resolved or 
they risk being indeterminate in CAP 1.0 and thus become interop issues.

> 2) As for what's the use of duplicate alarms, what if I want to send
> myself 20 e-mail messages to make sure I get the hint?  Or have 5 
windows
> opening with blinking text?  Who are we to say what a user might think 
is
> useful?

We already have prohibitions on duplicate repeat instances in iCalendar 
and we have duplicate BOOKED entry prohibitions in CAP so its not as if a 
duplicate, identical alarm prohibition would be that extraordinary.  These 
existing prohibitions are despite that some folks may consider concurrent 
repeat instances useful.

In any case, all of what you suggest can be done with autorepeating 
alarms:

     BEGIN:VALARM
     ACTION:EMAIL
     TRIGGER:-P1D
     REPEAT:20
     DURATION:PT1S
     ATTENDEE:MAILTO:[email protected]
     SUMMARY:*** REMINDER\: SEND AGENDA FOR IETF MEETING ***
     DESCRIPTION:Send out the draft agenda for the IETF WG Meeting 
tomorrow.  Attached is a
       pointer the document template for the agenda file.
 ATTACH;FMTTYPE=application/binary:http://host.com/templates/agenda.doc
     END:VALARM

     BEGIN:VALARM
     ACTION:EMAIL
     TRIGGER:-PT15M
     REPEAT:20
     DURATION:PT1S
     ATTENDEE:MAILTO:[email protected]
     SUMMARY:*** ANOTHER REMINDER\: SEND AGENDA FOR IETF MEETING ***
     DESCRIPTION:Send out the final agenda for the IETF WG Meeting today.
     END:VALARM

     BEGIN:VALARM
     TRIGGER:-PT10M
     REPEAT:5
     DURATION:PT1S
     ACTION:DISPLAY
     DESCRIPTION:IETF WG Meeting in Jabber 10:00 AM EST today!
     END: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...