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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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