Subject: [Simple] Comments Event Filter Function -01

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 13 Jul 2004 10:29:27 -0500

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

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.

Next, in the third paragraph, you have the example on [email-masked] & [email-masked], 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. 

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.

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.

Rgds/gf

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Wed, 14 Jul 2004 11:29:39 +0300

George,

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

> -----Original Message-----
> From: ext George Foti (QA/EMC) [mailto:[email-masked]]
> Sent: 13.July.2004 18:29
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Subject: Comments Event Filter Function -01
> 
> 
> Hi Hisham,
> 

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.

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
> 

Clarified.

> 
> Next, in the third paragraph, you have the example on 
> [email-masked] & [email-masked], 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.

> 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

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Thu, 15 Jul 2004 08:24:18 -0500

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.
Can U elaborate on the rationale for that.
Does it causes confusion for other cases
 
> 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.
If Bob was on the list and part of the domain, I dont see where to would you propagate the filter.

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.

---

From: [email-masked]
Date: Fri, 16 Jul 2004 11:00:18 +0300

> Sent: 15.July.2004 16:24
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
> Subject: RE: Comments Event Filter Function -01
> 
> 
> Comments inline Hisham
> /gf
> 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

> Your statement is true but thats not what the text in the 

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.

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

> 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

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Fri, 16 Jul 2004 06:18:31 -0500

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 16, 2004 4:00 AM
> To: George Foti (QA/EMC); [email-masked]
> 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:
> 
> You would propagate it to Bob's presence server. The RLS is 
> not the PS (although they can be co-located).
> 
> > 
> > 
> >