Subject: Re: ALARMID to VALARM after stored?

From: [email-masked]
Date: Mon, 11 Feb 2002 18:00:42 -0500

Doug wrote on 14-Nov-2001: 
> I think we should declare that this is a '1' and not
> a '0 or 1'.  Any CUA that gets a non-CAP object can
> easily add a ALARMID, but it would be a pain to add
> one later.

Just how does a CUA that added an ALARMID (or UID) to a VALARM keep track 
of it when a reschedule comes in from a non-CAP source?  There may be > 1 
VALARM on iCalendar stream and the order is not guaranteed to be 
preserved.  So how does a CAP client go about 'fixing up' the ALARMID on 
the update(s) to match those it created originally? 

Or does it just toss away any existing VALARMS and recreate and reassign 
new ALARMIDs?  This is somewhat problematic in that a CU can add their own 
VALARMs to the entry and blindly destroying all VALARMS and reassigning 
new ALARMIDs effectively removes any custom alarms they set.  It also 
makes doing sync hard/impossible in that depending on how ALARMIDs are 
re/assigned multiple instances may get created or worse, VALARMS may not 
get set as expected.

In the past there was no issue with "which VALARM was edited" because the 
entity was self contained; no deltas were sent.  As such, the VALARMs on 
the iCalendar stream were the ones that belonged.  In an attempt to make 
CAP utilize a delta model (one where only changes are sent over the wire) 
you introduce a set of problems we did not have when always sending a 
complete snapshot (ie: iTIP).  Im not sure that this proposal will solve 
the issue related to delta detection in multiple VALARMs if you have to 
also deal w/data that comes from outside CAP where there is no concept of 
having to deal w/it.

Perhaps its just the end of a long day and Im not seeing it so perhaps 
someone can explain how CAP<->non-CAP interactions where multiple VALARMs 
(or any other contained component for that matte) fully works when CAP is 
on the receiving side of the data...

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: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 17:33:33 -0700

[email-masked] wrote:
> Just how does a CUA that added an ALARMID (or UID) to a VALARM keep
> track of it when a reschedule comes in from a non-CAP source? 

I think this email you are quoting was part of my email (or thread)
that led to the discussion about how to tag data as local only.

The rest of that thread (and a new version of my proposal will
be out tomorrow night). 

> There
> may be > 1 VALARM on iCalendar stream and the order is not guaranteed
> to be preserved.  So how does a CAP client go about 'fixing up' the
> ALARMID on the update(s) to match those it created originally?

Fixing up?

I had proposed that SEQUENCE be used and not ALARMID. And
I had proposed a parameter that tagged as local only
and NEVER to be given to a non-owner.

> Or does it just toss away any existing VALARMS and recreate and
> reassign new ALARMIDs? 

I really don't think you think I think that :)

I had proposed how to tag local only VALARMS so that
there would never be any such conflict.

Global UID's have a similar problem. If we don't agree
how to tag local-only VALARMs, then it may be impossible to
REFRESH your entry and not blow away your VALARMs when
the CUA and CS are not from the same vendor.

> This is somewhat problematic in that a CU can
> add their own VALARMs to the entry and blindly destroying all VALARMS
> and reassigning new ALARMIDs effectively removes any custom alarms
> they set.  It also makes doing sync hard/impossible in that depending
> on how ALARMIDs are re/assigned multiple instances may get created or
> worse, VALARMS may not get set as expected.

I am not sure why you think that I proposed that a CUA blow
away existing VALARMS. At no point did I say that a CUA can
reuse ALARMIDs that already exist in a component.

> In the past there was no issue with "which VALARM was edited" because
> the entity was self contained; no deltas were sent.  As such, the
> VALARMs on the iCalendar stream were the ones that belonged.  In an
> attempt to make CAP utilize a delta model (one where only changes are
> sent over the wire) you introduce a set of problems we did not have
> when always sending a complete snapshot (ie: iTIP).  Im not sure that
> this proposal will solve the issue related to delta detection in
> multiple VALARMs if you have to also deal w/data that comes from
> outside CAP where there is no concept of having to deal w/it.

ALARMID was used as a way to say which VALARM you were referring
to in a VQUERY or MODIFY. At that time I don't recall that
we ever discussed local vs ORGANIZER VALARMs.

With my proposal (which I am re-writing), a CUA can tell
if they came from the ORGANIZER or not.

No matter what we do, existing CUAs will not uniquely tag the VALARMs.
But they don't have to because existing CUAs can only iTIP and
as you point out they will send the entire object again when
needed.

We are trying to figure out a way that will allow the full iTIP
and OLD CUAs to still work - and at the same time give new CUAs
the ability to tag VALARMS and a way for the CAP-CUA to 'know'
how to not send local-VALARMs back up the pipe to the iTIP only
ORGANIZER. Plus adding a new property to VALARM will not break
old CUAs - they simply will not know what to do with it.

> someone can explain how CAP<->non-CAP interactions where multiple
> VALARMs (or any other contained component for that matte) fully works
> when CAP is on the receiving side of the data...

Tomorrow.