[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> unique ids for VALARMs was already considered, and unique ids were
> considered good by almost everyone. From the archive, it appears
> was most heavily discussed November 2001-January 2002, and everyone
> seemed to agree that alarmids of some sort were useful. For
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"
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'
> a '0 or 1'. [Snip, snip]
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
> opening with blinking text? Who are we to say what a user might
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:
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.
SUMMARY:*** ANOTHER REMINDER\: SEND AGENDA FOR IETF MEETING
DESCRIPTION:Send out the final agenda for the IETF WG Meeting
DESCRIPTION:IETF WG Meeting in Jabber 10:00 AM EST today!
Messaging & Collaboration
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...