Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00

From: [email-masked]
Date: Tue, 3 Jun 2003 17:35:29 +0300

The body of a SUBSCRIBE may have many filters:

eg:

SUBSCRIBE
...
content-type: application/simple-filter+xml

filter id=1

filter id=2

filter id=3

Now, I want to remove filter 2. The way it is proposed now is to send a new SUBSCRIBE with filters 1 and 3. This is not efficient.

What I was proposing was sending filter 2 id indicating that it is deleted. Filters 1 and 3 are not sent and therefore remain on the server.

You propose hashing the whole body. How do I remove filter 2 in this case? Can you explain your proposal in more detail?

If the SUBSCRIBE includes multiple hashes, one for each filter, then it might work. Something like this (for removing filter 2):

SUBSCRIBE
...
content-type: application/simple-filter+xml

#(filter) id=1

#(filter) id=3

This is hardly an improvement.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Saturday, May 31, 2003 2:33 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: placing filters in refreshes, was: Re: [Simple] RE:
> Comments on draft-khartabil-simple-filter-funct-00
> 
> 
> It becomes really helpful if you ever run into a case where you want 
> to go back and forth between filters within the context of a 
> subscription.
> 
> -Jonathan R.
> 
> [email-masked] wrote:
> > Sounds like a reasonable idea. But the question is if its 
> more complicated that adding an element or attribute that 
> indicates removal of a filter using the filter id.
> > 
> > Regards,
> > Hisham
> > 
> > 
> >>-----Original Message-----
> >>From: ext Jonathan Rosenberg [mailto:[email-masked]]
> >>Sent: Thursday, May 29, 2003 8:08 PM
> >>To: Khartabil Hisham (NMP/Helsinki)
> >>Cc: [email-masked]; [email-masked]
> >>Subject: placing filters in refreshes, was: Re: [Simple] RE: 
> >>Comments on
> >>draft-khartabil-simple-filter-funct-00
> >>
> >>
> >>
> >>
> >>[email-masked] wrote:
> >>
> >>>>As I stated in my earlier email regarding the requirement draft I
> >>>>have a concern with the replace semantics of the filter criteria
> >>>>in the Subscribe. I am concerned that the filter criteria could
> >>>>become quite large especially if the watcher has different filter
> >>>>criteria for different presentities within presence lists. Do we
> >>>>need to have every refresh subscriptions include all the filter
> >>>>criteria for every presentity being watching everytime as our
> >>>>goal is bandwidth efficiency between the watcher and the network?
> >>>>I think that filter criteria will be modified by watchers a lot 
> >>>>less regularly than the period of refresh subscriptions and so it
> >>>>is better to have some very small extra overhead when creating,
> >>>>modifying or deleting the filter than having to include the
> >>>>filter criteria in every refresh. I think some similar
> >>>>functionality to the partial drafts may be the way forward here.
> >>>
> >>>
> >>>As I commented earlier, I share your concern and will look into it
> >>>before the next version of the I-D is released.
> >>
> >>I have an idea here.
> >>
> >>THe idea is that, instead of sending the filter, the 
> >>SUBSCRIBE refresh 
> >>includes a hash of the filter as the body of the request (with a 
> >>content-type along the lines of filter-hash or something). 
> The server 
> >>checks the hash to see if it maps against any existing filter 
> >>that has 
> >>been used in this dialog (and indeed, part of different 
> dialogs too - 
> >>would allow for sharing of filters). If so, the server acts 
> >>as if that 
> >>filter was in the body of the SUBSCRIBE. If not, it rejects teh 
> >>request and the client can re-try with the full filter.
> >>
> >>Basically, this is caching of filter documents, using a hash of the 
> >>document as a reference to a cache entry.
> >>
> >>-Jonathan R.
> >>
> >>-- 
> >>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> >>Chief Scientist                             Parsippany, NJ 
> 07054-2711
> >>dynamicsoft
> >>[email-masked]                     FAX:   (973) 952-5050
> >>http://www.jdrosen.net                      PHONE: (973) 952-5000
> >>http://www.dynamicsoft.com
> >>
> >>
> > 
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Tue, 03 Jun 2003 11:11:51 -0400

Hisham,

My responses below proceeded by [AA]

Regards
Andrew

Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id.

[AA] I think we also need to be able to add and modify filters without sending the entire filter document again so we need the filter id for that as well. The hash may help us with the out of synch detection and recovery problem. We will need a 4xx response code for when the hash is not found.

Regards,
Hisham

---

From: [email-masked]
Date: Tue, 03 Jun 2003 11:11:51 -0400

Hisham,

Regards
Andrew

Regards,
Hisham

---

From: [email-masked]
Date: Wed, 04 Jun 2003 04:29:35 -0400

Hisham, Jonathan,

My assumption was the same as that of Hisham. My thoughts were that there would not be a conflict problem as the result of multiple filters on the same document would effectively be combined together to form the output document. We just need to be careful that we don't produce duplicate tuples in the output.

In order to reliably modify, add and delete filters we need to ensure that we can detect and recover from situations when the client and the server get out of sync with what is the current version of the filter document. We either can use some document version numbering scheme or we can use the Hash scheme as Jonathan suggested for this. One advantage as I see of the hash is that it might be easier to use this to efficiently enable the client to select from a set of different baseline filter documents, (e.g the “at work” filters, the “at home” filters, etc) by using hashes of different versions that are stored on the server.  

I suggest that we use an empty ev-filter element for deletion. If the ev-filter element contains a valid id attribute already present in the filter document referenced by the hash and does not contain a What or Trigger element then this filter is removed from the filter document. If the ev-filter with a valid id attribute contains what and/or trigger elements then this indicates that the filter is to be modified to these new settings. If the ev-filter id attribute is new then this filter is added to the filter document. 

TO DELETE:

<ev-filter id = "mess" uri="sip:[email-masked]">
</ev-filter>

TO ADD OR MODIFY:

<ev-filter id = "mess" uri="sip:[email-masked]">
  <what>
   //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/descendant-or-self::*  | //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/ancestor::*
   </what>
 </ev-filter>

A new hash would be calculated for the current state of the filter document.

Andrew

---

From: [email-masked]
Date: Wed, 4 Jun 2003 17:08:21 +0300

If you send a subscription to a presence list and you want to have a separate filter for each member on that list, then you need separate filters (unless you count them as one filter with multiple rules).

Even if they are multiple rules within a filter, why shouldn't it be possible to manipulate one of those rules.

To answer your earlier question about reconciling them in case of conflict; I would say they don't conflict since they are destined for different resources.

Regards,
Hisham

> Sent: Wednesday, June 04, 2003 4:40 PM
> To: [email-masked]
> Cc: Khartabil Hisham (NMP/Helsinki); [email-masked]
> [email-masked] wrote:
> > 
> > Hisham, Jonathan,
> > 
> > My assumption was the same as that of Hisham. My thoughts were that
> > there would not be a conflict problem as the result of multiple
> > filters on the same document would effectively be combined together
> > to form the output document. We just need to be careful that we
> > don't produce duplicate tuples in the output.
> 
> I really dont understand the motivation behind this requirements for 
> multiple installed filters in parallel. Why can't you view the whole 
> combination as one big filter, and treat that as the thing which is 
> managed (i.e., installed, refreshed, deleted)? Just trying to 
> simplify. If you make that assumption, the whole problem 
> becomes a lot 
> easier.
> 
> -Jonathan R.
> 
> 
> --

---

From: [email-masked]
Date: Wed, 4 Jun 2003 17:08:21 +0300

Regards,
Hisham

---

From: [email-masked]
Date: Thu, 05 Jun 2003 06:21:00 -0400

Hisham, Jonathan,

In addition I am thinking that multiple applications may share the presence subscription and filters. For instance a messenger app and a chess game app. It seems simpler for the presence app in the client to simply combine seperate filters as seperate XML elements into one filter document than to try to produce a single XPATH filter expression from multiple input sources.

Andrew

---

From: [email-masked]
Date: Thu, 05 Jun 2003 06:21:00 -0400

Hisham, Jonathan,

Andrew