[Simple] RE: Comments Event Filter Function -01

["George Foti (QA/EMC)" <george.foti at ericsson.com>]

Hisham you wrote:

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

Co-location. Thats what I had in mind all along.
Thanks for the clarification.

Rgds/gf

> -----Original Message-----
> From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com]
> Sent: Friday, July 16, 2004 4:00 AM
> To: George Foti (QA/EMC); simple at ietf.org
> Subject: RE: Comments Event Filter Function -01
> 
> 
> 
> 
> > -----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