Subject: RE: [Simple] Event Filtering Issue 2: Propagating filters

From: [email-masked]
Date: Tue, 8 Jun 2004 14:07:28 +0300

A week has passed without comments on this issue. Therefore I conclude that the proposal I made below is acceptable.

Thanks,
Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext [email-masked]
> Sent: 31.May.2004 13:58
> To: [email-masked]
> Subject: [Simple] Event Filtering Issue 2: Propagating filters
> 
> 
> Current text: "If the URI indicated by the filter is for one 
> resource who's URI is NOT one of the URIs that result from a 
> lookup, by the RLS, on the   Request-URI, the filter is 
> propagated to all the fanned out subscriptions."
> 
> For example: I we have 2 lists, each located on its own RLS:
> 
>    List1 ([email-masked]) on RLS1 has:
>         [email-masked]
>         [email-masked] 
>    List2 on RLS2 has:
>      [email-masked]
> 
> (Note: list2 is a resource in list1)
> 
> RLS1 receives the following SUBSCRIBE request:
> - The SUBSCRIBE is for list1
> - contains 2 filters: one for [email-masked] and the 
> other for [email-masked]
> 
>    SUBSCRIBE sip:[email-masked] SIP/2.0
>    ...
>    <?xml version="1.0" encoding="UTF-8"?>
>       <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
>                   xmlns:pidf="urn:ietf:params:xml:ns:pidf">
>          <filter id="999" uri="sip:[email-masked]">
>             <what>
>                <include 
> type="namespace">urn:ietf:params:xml:ns:pidf</include>
>                <exclude>//pidf:tuple/pidf:note</exclude>
>             </what>
>          </filter>
>          <filter id="8439" uri="sip:[email-masked]">
>             <what>
>                <include>//pidf:tuple/pidf:status/pidf:basic</include>
>             </what>
>          </filter>
>    </filter-set>
> 
> RLS1 fans out subscriptions to resources on list1. The 
> current text suggests that all filters are propagated to RLS2 
> since both [email-masked] and [email-masked] are not 
> resources in [email-masked].
> 
> There was a suggestion that if a filter is destined to a 
> resource that is part not part of the list and is outside the 
> administrative domain of an RLS, then that filter is 
> propagated. The rest are consumed. In our example, only the 
> filter to [email-masked] is propagated since example2.com 
> is not under the administrative domain of RLS1. The filter to 
> [email-masked] is consumed.
> 
> This causes problems since [email-masked] could have been 
> part of list2. The subscriber knows this but RLS1 doesn't.
> 
> So, there were 3 proposals:
> 
> 1. propagate all the filters to URIs not on the list
> 
> 2. propagate only filters destined to URIs not on the list 
> and are not part of the administrative domain of the RLS 
> creating the fanned out subscriptions.
> 
> 3. State only that the subscriber makes an agreement with the 
> RLS and do not specify how the RLS fulfils the agreement.
> 
> The 3rd proposal was brought up in the interim. I'm not sure 
> if it is the best alternative. RLSs have to do something 
> anyway and I think it is better to specify what that is. This 
> will enhance interoperability and client expectations.
> 
> I propose 2 with the modification that an RLS must maintain 
> those filters it consumed and must somehow apply them to 
> notifications it received.
> 
> Regards,
> Hisham
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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