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

From: [email-masked]
Date: Mon, 31 May 2004 13:57:48 +0300

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