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

From: [email-masked]
Date: Fri, 30 May 2003 18:06:11 +0300

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
> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 19:32:41 -0400

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 19:32:41 -0400

-Jonathan R.