[Simple] RE: Comments Event Filter Function -01

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: ext George Foti (QA/EMC) [mailto:george.foti at ericsson.com]
> Sent: 15.July.2004 16:24
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple at ietf.org
> Subject: RE: Comments Event Filter Function -01
> 
> 
> Comments inline Hisham
> /gf
> > Removing a filter is done in one way. Replacing a filter is 
> > done in another way. Two filters to the same user is an 
> > error. Having those 2 filters appear in the same request or 
> > in separate requests does not make a difference. We shouldn't 
> > overload the functionality. If something is clearly an error 
> > (trying to replace a filter in a different way than is 
> > specified), then the client must be told about it.
> > 
> I dont get it.
> To modify an existing filter for a resource. I have 2 
> possible alternatives here :
> 1) Use the same filterid with a new content.
> 2) Use a new filterid that implicitly removes the old filter 
> for that user and replace it with the new filter. That 
> respects the rule of having one filter per resource.
> 
> You seem to say that 2 is an error, and we should do that in 
> 2 steps, first an explict remove, then add the new filter.

What you are asking for is a filter replacement. For this, it is defined that the same filter-id is used with new filter contents. It's just 1 step.

Adding new filters is done using new filter-ids. If this new filter has a URI that conflicts with another filter URI, then it is an error.

So:

1. Removing is done using the remove attribute
2. Replacing/modifying is done by re-using the filter-id
3. Adding is done by creating new filter with new filter id

> Can U elaborate on the rationale for that.
> Does it causes confusion for other cases
>  
> > > 
> > > Next, in the third paragraph, you have the example on 
> > > myboddies at mydomain.com & bob at mydomain.com, it seems to me 
> > > that the domain must be different for the RLS to extract the 
> > > filter and propagate it, so Bob should have a different 
> > > domain for the statement to apply. 
> > 
> > The example is correct. A filter is not propagated if Bob was 
> > not part of the list, but is part of domain.com.
>  
> Your statement is true but thats not what the text in the 
> draft is saying.

There is text for that:

"There may be
   situations where the filters were not propagated because they address
   a URI that in under the adminstrative domain of the RLS, but are not
   part of the resource list that the subscription was addressed to.  In
   this case, it is the RLS responsibility to make sure than those
   filters are applied to notifications issued."

I'll make this text more normative.

> If Bob was on the list and part of the domain, I dont see 
> where to would you propagate the filter.

You would propagate it to Bob's presence server. The RLS is not the PS (although they can be co-located).

> 
> 
> 
> I had one comment I forgot to mention.
> In section 5.2.1 you talk about mismatch between the R-RI in 
> SUBSCRIBE and URI in the filter.
> It would help to expand what mismatch means.
> I know you cover it in several places in the document.
> Optionally refer to the section where one can find the pertinent text.
> 
> 

Added some text about this in all sections that imply URI matching is needed.

Thanks,
Hisham

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple