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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jun 2003 17:33:32 -0400

inline.

[email-masked] wrote:
> 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.

Ah, I had a different model in mind.

What I had in mind was that there is one filter installed per 
subscription at a time. THis filter may itself have multiple rules, 
but the granularity of operations are on the level of filter. You are 
assuming rather that multiple filters are installed at once. What does 
that mean? How do you reconcile them in case they conflict?

> 
> 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?

In the one-filter model, you would remove a filter simply by sending a 
re-SUBSCRIBE with no body. Thus, there is no hash needed to remove. 
You would use a hash to (re-)enable a filter.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jun 2003 17:33:32 -0400

inline.

-Jonathan R.