Subject: [Simple] Issue with comparisons for triggerring

From: "Sean Leahy" <[email-masked]>
Date: Mon, 6 Mar 2006 14:14:39 +0000

When considering the filtering of preferred information using 'triggers', 
the child elements 'changed' ('from', 'to', and/or 'by'), 'added' or 
'removed' refer to a comparison between current and previous XML 
documents. The 'previous XML document' is 'the last XML document that was selected for delivery to that specific 
subscription before any filter was applied to it' [draft-ietf-simple-filter-format-05].

This requirement is self-contradictory. Although it implies that attention 
is given to specific subscriptions during the comparison process, it 
actually (and conversely) supports comparisons of versions on a per 
presentity rather than on a per subscriber basis.  Subscriber specific 
versions are only created after filtering of the 'raw presence document'. The trigger that eventually determines 
whether a document is delivered on a specific subscription is part of the 
filter process that is excluded from the comparison. 

e.g. when a trigger such as 'Status changed from value A to value C' is 
specified but the Status changes in practice from value A to value B and 
then again to value C. The result is that the document would not be 
delivered when the Status changes to value C (the document that was 
previously selected for delivery BEFORE any filter [e.g. current trigger] was applied had the Status value B ). The remedy is for the watcher to 
set the trigger appropriate to what is required e.g. 'Status changed to 
value C' rather than  'Status changed from value A to value C'.

Another example is when a trigger such as 'changed by 2' is used and the 
last value of the element / attribute was '6' but the element / attribute 
actually changes to '7' then changes again to '8'. The result is that the 
document would not be delivered when the value changes to 8 because it has 
only changed by 1 with respect to the last (undelivered) version (the 
document that was previously selected for delivery BEFORE any filter [e.g. current trigger] was applied had the element / attribute value 7 ). 

The results meet the formal requirement and also minimise the scalability 
issues that would otherwise be associated with keeping previous versions 
of notifications on every subscription that has a trigger active. However, 
they may not meet the expectations of watchers that have interpreted the 
requirement differently i.e. stressed "the last XML document that was 
selected for delivery to that specific subscription" and ignored the fact 
that "before any filter was applied to it" excludes the operation of the 
trigger itself !

If the intention (contrary to the stated requirement) is that the presence 
server must retain the last delivered set of information for every 
subscription involving filters that include triggers, have the scalability 
issues been considered ?

Note: This problem does not affect  the child elements 'added', 'removed' 
or 'changed to', it only affects 'changed from to' and 'changed by' or to 
put it another way it is the inclusion of support for  'changed from to' 
and 'changed by' that creates the <scaleability> problem. Perhaps, support 
for these particular combinations of child elements should at least be 
optional ?

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 6 Mar 2006 17:20:32 +0100

On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote:

>
> When considering the filtering of preferred information using 
> 'triggers', the child elements 'changed' ('from', 'to', and/or 'by'), 
> 'added' or 'removed' refer to a comparison between current and 
> previous XML documents. The 'previous XML document' is 'the last XML 
> document that was selected for delivery to that specific subscription 
> before any filter was applied to it' 
> [draft-ietf-simple-filter-format-05].

You are making a false assumption about the above quoted sentence. 
Nothing in that sentence says that the XML document was not sent. But 
if you misread it that way, then I guess it needs rephrasing.

>
>
> This requirement is self-contradictory. Although it implies that 
> attention is given to specific subscriptions during the comparison 
> process, it actually (and conversely) supports comparisons of versions 
> on a per presentity rather than on a per subscriber basis.  Subscriber 
> specific versions are only created after filtering of the 'raw 
> presence document'. The trigger that eventually determines whether a 
> document is delivered on a specific subscription is part of the filter 
> process that is excluded from the comparison.
>
> e.g. when a trigger such as 'Status changed from value A to value C' 
> is specified but the Status changes in practice from value A to value 
> B and then again to value C. The result is that the document would not 
> be delivered when the Status changes to value C (the document that was 
> previously selected for delivery BEFORE any filter [e.g. current 
> trigger] was applied had the Status value B ). The remedy is for the 
> watcher to set the trigger appropriate to what is required e.g. 
> 'Status changed to value C' rather than  'Status changed from value A 
> to value C'.
>
> Another example is when a trigger such as 'changed by 2' is used and 
> the last value of the element / attribute was '6' but the element / 
> attribute actually changes to '7' then changes again to '8'. The 
> result is that the document would not be delivered when the value 
> changes to 8 because it has only changed by 1 with respect to the last 
> (undelivered) version (the document that was previously selected for 
> delivery BEFORE any filter [e.g. current trigger] was applied had the 
> element / attribute value 7 ).
>
> The results meet the formal requirement and also minimise the 
> scalability issues that would otherwise be associated with keeping 
> previous versions of notifications on every subscription that has a 
> trigger active. However, they may not meet the expectations of 
> watchers that have interpreted the requirement differently i.e. 
> stressed "the last XML document that was selected for delivery to that 
> specific subscription" and ignored the fact that "before any filter 
> was applied to it" excludes the operation of the trigger itself !
>
> If the intention (contrary to the stated requirement) is that the 
> presence server must retain the last delivered set of information for 
> every subscription involving filters that include triggers, have the 
> scalability issues been considered ?

Why is there a scalability issue? Since you only need to retain a copy 
of the last sent XML document to the subscriber *before filtering is 
applied*, my guess is that it will be the same for all it was sent to. 
You just need to mark it with something that indicates who received it. 
I don't think that will cause scalability issues.

Regards,
Hisham

>
> Note: This problem does not affect  the child elements 'added', 
> 'removed' or 'changed to', it only affects 'changed from to' and 
> 'changed by' or to put it another way it is the inclusion of support 
> for  'changed from to' and 'changed by' that creates the 
> <scaleability> problem. Perhaps, support for these particular 
> combinations of child elements should at least be optional 
> ?_______________________________________________
> Simple mailing list
> [email-masked]