Subject: (#1) synchronization part 2, and identifying a components VALARM

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 22:32:51 -0700

Outstanding CAP problems:

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

     How do you tag VALARMS (or any component) as local so that
     when you do synchronization or new iTIP object arrive,
     the local VALARMS do not get tossed out because they
     were mistakenly seen as old data.

     How do you disable VALARMS that came in as part of a
     METHOD:REQUEST without deleting them. They can not be deleted
     because if the CUA wishes to send a METHOD:COUNTER, you need
     to include the entire object and only change or delete what
     you are proposing in the COUNTER to change or the ORGANIZER
     would assume that part of the COUNTER was to delete the VALARM.

 Proposal:
 
         (1) Add SEQUENCE as a MUST for VALARM in the CS
             that starts at zero (0). If the incoming object does
             not have any, then the CUA MUST add them before depositing
             them in the CS.
 
             This would make them unique per object and solve the
             MODIFY problem.

	     The CUA would have to compare the contents of any
	     updated iTIP objects that arrive without SEQUENCE
             to determine what changes have been made in order
             to synchronize and update the CS and CUA objects.
              
         (2) Create a new LOCAL parameter for the SEQUENCE property.
 
             The default value if not specified is 'false', and
             can be set to 'true'. Where 'true' means only visible
             to the calendar owners(s) and 'local' VALARMS MUST NOT
             be sent to non-calendar-owner(s) during queries.
 
             This would allow global (ORGANIZER originated VALARMs),
             and local (OWNER originated VALARMs) to have numbers
	     starting at zero and not have to coordinate them between
	     the OWNER and ORGANIZER.
 
                 BEGIN:VALARM
                 SEQUENCE:0
                 ...
                 END:VALARM
                 BEGIN:VALARM
                 SEQUENCE;LOCAL=true:0
                 ...
                 END:VALARM
 
             This would solve the synchronization problem by
	     uniquely identifying the local VALARMS to the CS
             and CUA so local VALARMs do not get tossed when a
	     higher SEQUENCE number arrives in an iTIP object.
 
         (3) Add a new ENABLE parameter to TRIGGER with a default
             value of 'true', and could be set to 'false'. If
             not specified it default to 'true'.
 
             And ENABLE is local to the calendar ONLY. That means
             the ORGANIZER MUST NOT set or specify ENABLE, and the
             CS MUST NOT export the ENABLE parameter to non-owners
             of the object during queries.
 
             This would allow local users to enable or disable
             both local and global VALARMS.
 
                 ...
                 BEGIN:VALARM
                 SEQUENCE:2
                 TRIGGER;ENABLE=false:20020101T000000Z
                 SUMMARY:NEW YEAR
                 ...
                 END:VALARM
                 BEGIN:VALARM
                 SEQUENCE;SCOPE=local:0
                 TRIGGER:20020101T000000
                 SUMMARY:NEW YEAR
                 ...
                 END:VALARM
                 ...

 Now with this the ORGANIZER can modify VALARMS, and the local
 owner can decide the users preferences for TRIGGERS.  I think this
 solves the MODIFY problem by uniquely identifying VALARMS in each
 object (by using SEQUENCE and LOCAL) and gives the local user control
 over VALARM TRIGGERs without breaking synchronization.

---

From: Mark Paterson <[email-masked]>
Date: Fri, 15 Feb 2002 09:27:09 -0500

At 10:32 PM 2/13/2002 -0700, you wrote:

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

How do you tag VALARMS (or any component) as
local so that

when you do synchronization or new iTIP object
arrive,

the local VALARMS do not get tossed out because
they

How do you disable VALARMS that came in as part
of a

METHOD:REQUEST without deleting them. They can
not be deleted

because if the CUA wishes to send a
METHOD:COUNTER, you need

to include the entire object and only change or
delete what

you are proposing in the COUNTER to change or
the ORGANIZER

would assume that part of the COUNTER was to
delete the VALARM.

Proposal:

(1) Add SEQUENCE as a
MUST for VALARM in the CS

them in the CS.

MODIFY problem.

(2) Create a new LOCAL
parameter for the SEQUENCE property.

the OWNER and ORGANIZER.

BEGIN:VALARM

SEQUENCE:0

...

END:VALARM

BEGIN:VALARM

SEQUENCE;LOCAL=true:0

...

END:VALARM

(3) Add a new ENABLE
parameter to TRIGGER with a default

...

BEGIN:VALARM

SEQUENCE:2

SUMMARY:NEW YEAR

...

END:VALARM

BEGIN:VALARM

SEQUENCE;SCOPE=local:0

Shouldn't that be SEQUENCE;LOCAL=true;0 like you did above ?

TRIGGER:20020101T000000

SUMMARY:NEW YEAR

...

END:VALARM

...

owner can decide the users preferences for TRIGGERS.  I think
this

solves the MODIFY problem by uniquely identifying VALARMS in
each

object (by using SEQUENCE and LOCAL) and gives the local user
control

over VALARM TRIGGERs without breaking
synchronization.

Agree. Your alarms are yours and shouldn't interfere with the actual ITIP
workflow. These provisions should allow a CUA to let an attendee set up
their own alarms and keep them up-to-date without messing with the rest
of the works.

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Sat, 16 Feb 2002 10:40:09 -0700

> Shouldn't that be SEQUENCE;LOCAL=true;0 like you did above ?

They are independent. You can ENABLE or disable a GLOBAL
VALARM trigger. That allows a CU to ignore any VALARMs in
their calendar if needed that were added as part of 
a REQUEST, PUBLISH, or whatever.

---

From: Mark Paterson <[email-masked]>
Date: Mon, 18 Feb 2002 10:10:31 -0500

At 10:40 AM 2/16/2002 -0700, you wrote:

Mark Paterson wrote:

...

BEGIN:VALARM

SEQUENCE:2

SUMMARY:NEW YEAR

...

END:VALARM

BEGIN:VALARM

SEQUENCE;SCOPE=local:0

I'm not referring to the ENABLE example. Further up in your message you
had an example with LOCAL=true and here you've used SCOPE=local. Are
these different? or was one of the examples in error?

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Feb 2002 10:24:15 -0700

Mark Paterson wrote:
> I'm not referring to the ENABLE example. Further up in your message
> you had an example with LOCAL=true and here you've used SCOPE=local.
> Are these different? or was one of the examples in error?

Sorry - yes - SCOPE was the name I used in my 1st propopsal.
Now SCOPE is used in VCARs. Yes - ENABLE - thanks.