First discussion telco May 8, 2012:

Two possible solutions:
(1) Add second Refresh method that operates on a monitored item
(2) Add a property to the ConditionType that indicates if the event was from a refresh

Agreed in telco that this will not be addressed in v1.02

Agreed to document the possibility of clients getting duplicate, unsolicited duplicate event notification. Document the "workaround" for clients is to use individual (multiple) subscriptions to prevent this.

Agreed to include in 1.03

We should add a Method ConditionRefresh2(SubscriptionId, MonitoredItemId) to 1.03. This is the only good long term solution. Since the method is only defined on the ConditionType, this would not affect instances.

An Alarm client can check for availability of this method and can call the old ConditionRefresh if the new one is not available.

Aded text to explain expected behaviour is multiple monitored item are in the subscription.

Did not add ConditionRefresh2. First we need to discuss how this will be compliance tested. It will be a 1.03 functionality and the CTT will need to be able to determine this and test accordingly.

Added ConditionRefresh2 method that include the Monitored item

We reviewed all the text, but Paul needs to add Refresh2 to a figure.

I have several change requests to the new method:

(1) Name of second parameter should be MonitoredItemId
This is the name of the parameter returned from CreateMonitoredItems

(2) Parameter description
SubscriptionId
Identifier of the subscription. The Server shall verify that the SubscriptionId provided is part of the Session that is invoking the Method.
MonitoredItemId
Identifier of the MonitoredItem to refresh.

(3) MonitoredItem is written as term in Part 4

(4) Remove ..... from method signature

updated text as requested

Agreed to text edited in telecon.