Subject: RE: [Simple] Filtering - trigger evaluation

From: <[email-masked]>
Date: Fri, 24 Feb 2006 13:45:08 +0100

After a discussion, we have found the following use case. Could anyone comment it? Is my understanding of that issue right?

1. Client A subscribes to the presence document of client B. Client A sends a filter with such trigger in a body of the SUBSCRIBE request that sends notify message iff some particular element E is changed from value 10 to value 20.

2. An initial NOTIFY message is sent to the client A - the value of E is 10.

3. The B's presence document changes its state so now E has got 20. Notification is sent to client A.

4. The B's presence document changes again. E's value is now 10. Nothing is sent to client A.

5. E's value changes back to 20. However, last notification sent to client A contained element E with value 20, too, so no notification is sent to client A. Moreover, notification is NEVER MORE sent...

Could you please comment this?

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Friday, February 24, 2006 12:50 PM
> To: Burda Michal
> Cc: [email-masked]
> Subject: Re: [Simple] Filtering - trigger evaluation
> 
> The filter was built according to what the subscriber has, so I would
> say the last notification that was really sent to client A
> (notification from step 2) is the one used.
> 
> Hisham
> 
> On Feb 24, 2006, at 9:14 AM, <[email-masked]> wrote:
> 
> >
> > Hi everybody,
> >
> > I'm working on some topics related to Event notification filtering and
> > I have reached an issue, which solution is not completely defined in
> > specification. Could someone answer me some questions?
> >
> > The problem is as follows:
> > 1. Client A subscribes to the presence document of client B. Client A
> > sends a filter with trigger in a body of the SUBSCRIBE request.
> > 2. Client A receives notification.
> > 3. Client B's presence state changes, so the notification has to be
> > sent, but the filtering trigger blocks that notification, so nothing
> > is sent to client A.
> > 4. Client B's presence state changes again...
> >
> > Which "old" presence document has to be used together with the fresh
> > one in order to evaluate filtering triggers? Is it a notification body
> > that was produced (but has not been sent) in step 3? Or is it the last
> > notification that was really sent to client A (notification from step
> > 2)?
> >
> > Thanks for any suggestions
> >
> >
> > Best regards,
> >
> > Michal Burda
> > Software Specialist
> >
> > TietoEnator a.s.
> > Czech Software Centre
> > Direct: +420 599 096 020
> > Fax: +420 599 096 110
> > E-mail: [email-masked]
> > Výstavní 292/13
> > CZ-709 16 Ostrava
> > CZECH REPUBLIC
> >
> > www.tieotoenator.com
> >
> > Please note: The information contained in this message may be legally
> > privileged and confidential and protected from disclosure. If the
> > reader of this message is not the intended recipient, you are hereby
> > notified that any unauthorised use, distribution or copying of this
> > communication is strictly prohibited. If you have received this
> > communication in error, please notify us immediately by replying to
> > the message and deleting it from your computer. Thank you.
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple

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

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 24 Feb 2006 15:43:46 +0100

Yes that is correct behaviour. The subscriber needs to update filters 
if s/he wishes for new information to come.

Hisham

On Feb 24, 2006, at 1:45 PM, <[email-masked]> wrote:

> After a discussion, we have found the following use case. Could anyone 
> comment it? Is my understanding of that issue right?
>
> sends a filter with such trigger in a body of the SUBSCRIBE request 
> that sends notify message iff some particular element E is changed 
> from value 10 to value 20.
>
> 5. E's value changes back to 20. However, last notification sent to 
> client A contained element E with value 20, too, so no notification is 
> sent to client A. Moreover, notification is NEVER MORE sent...
>
>