Subject: [Fwd: Re: [Ietf-calsify] possible VALARM solution?]

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 7 11:14:11 2004

[resend - sent to wrong list...]

[email-masked] wrote:

> It would be desirable for the UI of a CUA to ask you, at import/open 
> time, whether you want to:
>
>         1. Ignore alarms entirely - don't set them.
>         2. Import the alarms using client defaults
>         3. Ask the user what kind of alarm to set, for each one imported
>
> UIs of course, are outside of the scope of the simplification work - 
> but the above 3 choices would work whether we retain the transmission 
> of VALARMs, or we simplify by having a REMINDER=YES/NO 
> parameter/property.

CAP adds a LOCAL and ENABLE objects to VALARM for just that purpose.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040907/adfeea72/smime.bin

---

From: TimHare at comcast.net ([email-masked])
Date: Tue Sep 7 17:13:42 2004

Right - but _adding_  objects/components/properties takes us away from our 
simplification goal, and simplification is being discussed to improve 
interoperability.

The many pieces of CAP are there to try to accomodate almost everything 
that existing implementations do - which is a different way to accomplish 
interoperability, but not a simple one.

At 02:13 PM 9/7/04, Doug Royer wrote:

>CAP adds a LOCAL and ENABLE objects to VALARM for just that purpose

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 7 18:08:54 2004

[email-masked] wrote:

> Right - but _adding_  objects/components/properties takes us away from 
> our simplification goal, and simplification is being discussed to 
> improve interoperability. 

Yes it adds. Interoperability is the other goal. And that is part of 
this debate.

Its simply a standardized way to tag the data so that cross vendors can tell
tell that the CU already answered your questions.

If you get a PUBLISH with a VALARM, the user says don't set them.
Do you delete the alarm and store the object without the alarm?
Or do you somehow remember that the alarm is to be ignored?

Now you get an update to that PUBLISHed object (which still
contains its valarm) , the LOCATION is changed, do you ask again?

Or do you remember that you said no to the alarm? How? Does your
way work with another vendor?

If you deleted the valarm then the new update looks like a new alarm - 
correct?
So you ask again and delete it again?

The CAP solution was to store the VALARM with a ENABLE=FALSE
parameter and not delete the valarm. Now you know that UID:123 VALARM is 
to be ignored
from any vendors CUA no matter how may updates are sent to the same object.

This also solves the problem of unwanted action types 
(PROCEDURE/AUDIO/...) alarms
from imported alarms that may be updated over time. The CUA can always set
PROCEDURE alarms to disabled in a way that other CUAs can tell.

Its not simple if its not interoperable.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040907/115bf683/smime.bin