[Simple] RE: Comments Event Filter Function -01

[hisham.khartabil at nokia.com]

George,

I appreciate you taking time to review this draft. Responses inline...

> -----Original Message-----
> From: ext George Foti (QA/EMC) [mailto:george.foti at ericsson.com]
> Sent: 13.July.2004 18:29
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks at dynamicsoft.com;
> simple at ietf.org
> Subject: Comments Event Filter Function -01
> 
> 
> Hi Hisham,
> 
> I have the following comments on the subject draft:
> 
> 1) Section 3.3.3 : Changing Filters Within a Dialog
> 
> First, small typo -  3 lines from the bottom:  "changing" 
> instead of "chaning".

Done.

> Next, why do we want to consider an error condition the case 
> when a new filter is defined with new contents but reference 
> an existing  resource (that already had a previuosly defined 
> filter wih a different filter id).
> Why not simply remove the old filter for that resource and 
> replace that with the newly defined filter for that resource.
> Otherwise the only way to define a new filter for such a 
> resource would be to explictly remove the old filter first 
> then define a new one.
> This way you have uniform treatment for all cases.

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.

> 
> If you are OK with that one, then there are several  places 
> in the draft where that needs to be reflected.
> 
> 2) Section 4.1
> 
> First, can you please add the following clarification to the 
> text in the second paragraph
> 
>  If no URI is indicated by the filter, the filter applies to all the
>    notifications that the RLS issues for the R-URI. 
>  If the URI indicated by the filter is a list URI, the filter 
> applies to all the notifications
>    that the RLS issues for the list in the filter URI.

Clarified.

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

> 
> Finally, in the paragraph  before the last one, where the 
> filter applies to a domain, you state that the RLS MUST NOT 
> apply any filter to any notifications it sends, but instead 
> MUST forward the filter with all fanned oiut subscriptions to 
> the notifiers. 
> You should qualify that statement, that it only applies if 
> the domain is a different domain then the one that to which 
> the RLS belongs.

It needs to since filters need to reach the presence server, for example, and that server could be different than the RLS.

> 
> 3) Section 4.2
> Minor typo , fourth line from the bottom:  "of" instead of "oif".
> 
> 4) Section 5.2
> 
> Minor typo first line: "additional"  instead of "addition"
> 
> 5) Section 5.3.1
> Fist paragraph, you state that the NOTIFY being sent after a 2xx
>    response to the original SUBSCRIBE MUST be populated
>    according to the filter.  
> 
> Using a strength of *MUST* contradicts what you state in 
> section 5.3 that the NOTIFY  following a 202 could be used to 
> terminate the subscription.
> 
> Align the 2 sections.

All done.

Thanks,
Hisham

> 
> Rgds/gf
> 
> 
> 

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