rfc4660 functional description of event notification filtering.txt

有关IMS SIP及Presence应用的RFC文档包

4.1.  Request-URI vs. Filter URI

   If the URI is not defined within the filter, the filter applies to
   the resource list identified in the Request-URI of the SUBSCRIBE
   request.  This results in the filters being applied to all the
   notifications that the RLS issues to this subscription.  The same
   processing applies to a filter that defines a URI that matches the
   request-URI of the SUBSCRIBE request.  That is, the filter applies to
   all notifications that the RLS issues to this subscription.

   If the URI indicated by the filter is for one resource whose URI is
   one of the URIs that result from a lookup by the RLS on the
   Request-URI, the filter for that particular resource is extracted and
   propagated in the SUBSCRIBE request sent to that resource.  It is
   possible to have more than one filter in a SUBSCRIBE request body,
   and therefore a filter specific to a resource MUST be extracted and
   only that one is propagated.  For example, if the Request-URI in a
   SUBSCRIBE has the value "sip:[e-mail]", where
   "[e-mail]" is a resource belonging to that list, and the URI
   in a filter is "sip:[e-mail]", the filter specific for Bob is
   extracted and placed in the body of the SUBSCRIBE sent to
   "[e-mail]".

   If the URI indicated by the filter is for one resource whose URI is
   NOT under the RLS administrative control, the RLS propagates the
   filter to all the fanned out subscriptions.  This is to accommodate
   the scenario where the subscriber knows that there are sub-lists in
   the event list that are under a different administrative domain from
   that where the original subscription was sent, and the subscriber
   wishes to set a filter for a resource in that sub-list.

   If the URI indicated by the filter is for one resource whose URI is
   under the RLS administrative control but is not part of the resource
   list that the subscription was addressed to, the filter is not
   propagated.  In this case, it is the RLS's responsibility to make
   sure that this filter is applied to notifications issued, if
   information about that resource is present.








Khartabil, et al.           Standards Track                     [Page 7]

RFC 4660          Functional Description of Filtering     September 2006


   For example: If we have 2 lists, each located on its own RLS:

   List1 ([e-mail]) on RLS1 has: [e-mail]

   [e-mail]

   List2 on RLS2 has: [e-mail] [e-mail]
   (Note: list2 is a resource in list1)

   RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is
   addressed to list1 and contains 2 filters: one for [e-mail]
   and the other for [e-mail]):

   SUBSCRIBE sip:[e-mail] SIP/2.0
   ...
   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
     <ns-bindings>
       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
     </ns-bindings>
     <filter id="999" uri="sip:[e-mail]">
       <what>
         <include type="namespace">
           urn:ietf:params:xml:ns:pidf</include>
         <exclude>
           //pidf:tuple/pidf:note</exclude>
       </what>
     </filter>
     <filter id="8439" uri="sip:[e-mail]">
       <what>
         <include>
           //pidf:tuple/pidf:status/pidf:basic</include>
       </what>
     </filter>
   </filter-set>

   RLS1 fans out subscriptions to resources on list1.  The text above
   suggests that if a filter is destined to a resource that is 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 [e-mail] is propagated since biloxi.com is
   not under the administrative domain of RLS1.  The filter to
   [e-mail] is consumed, and RLS1 needs to apply that filter to
   notifications it receives.

   URI matching is done according to the matching rules defined for a
   particular scheme (SIP URI matching rules are defined in RFC 3261
   [2]).



Khartabil, et al.           Standards Track                     [Page 8]

RFC 4660          Functional Description of Filtering     September 2006


   A filter may also be addressed to a domain using the 'domain'
   attribute instead of the 'uri' attribute.  In this case, the filter
   applies to resources in that domain, and the RLS MUST NOT apply
   filters to any notifications it sends.  Instead, it MUST forward the
   filter with all fanned-out subscriptions to the notifiers.

   As indicated in Section 3.3.1, multiple filters can be present in a
   SUBSCRIBE request.  Filters can also be added or modified as
   indicated in Section 3.3.3.  In such circumstances, an RLS MUST check
   that there are no filters addressed to the same resource or domain,
   and if there are, it MUST reject the SUBSCRIBE request with a "488"
   error response.

4.2.  Changing Filters within a Dialog

   If an RLS receives a subscription refresh request with no filters
   specified (empty payload), the RLS assumes that the client does not
   wish to update the filters.  If an RLS receives a subscription
   refresh with a filter containing the 'remove="true"' attribute, as
   defined in [5], the RLS assumes that the client is removing that
   filter identified by the filter ID.

   If an RLS receives a subscription refresh request with a filter that
   already exists (i.e., having the same filter ID), the RLS interprets
   it as a replacement of the existing filter.  Replacing a filter by
   changing the filter ID and keeping the resource URI is considered an
   error since this causes the RLS to assume that two filters are in
   place for the same resource.

   A filter can be disabled and re-enabled using the 'enabled' attribute
   in the <filter> element, as described in [5].

5.  Server Operation

5.1.  NOTIFY Bodies

   SIP entities compliant with this specification MUST support
   content-type 'application/simple-filter+xml'.

5.2.  Notifier Processing of SUBSCRIBE Requests

   This section presents additional functionality required from the
   notifier when filters are used in the bodies of the SUBSCRIBE
   requests.  Normal package-specific functionality is otherwise
   followed.






Khartabil, et al.           Standards Track                     [Page 9]

RFC 4660          Functional Description of Filtering     September 2006


   The notifier will examine the Content-Type header field and will
   return a 415 response if it does not understand the content type
   'application/simple-filter+xml'.

   A 200-class response indicates that the subscription has been
   accepted, and the NOTIFY will be sent immediately.  A "200" response
   indicates that the subscription has been accepted, the user is
   authorized, and the filter is accepted.  A "202" response merely
   indicates that the subscription has been understood, but that the
   authorization may or may not have been granted.  A "202" response
   also indicates that the filters have not been accepted yet.  The
   acceptance of the filters MAY arrive in a subsequent NOTIFY.

   Procedures described in Section 5.4 are followed if an error is
   encountered.

   As indicated in Section 3.3.1, multiple filters can be present in a
   SUBSCRIBE request.  Filters can also be added or modified as
   indicated in Section 3.3.3.  In such circumstances, a server MUST
   check that there are no filters addressed to the same resource or
   domain, and if they are, it MUST reject the SUBSCRIBE request with a
   "488" error response.

5.2.1.  Request-URI vs. Filter URI

   The subscriber may have chosen to leave the URI in the filter
   undefined.  If the URI is not defined within the filter, the filter
   applies to the resource identified in the Request-URI.

   Similarly, the subscriber may have chosen to include a URI in the
   filter.  In this case, the filter applies to all notifications sent
   with content associated with the resource with that URI for this
   subscription.  If the Request-URI and the URI in the filter do not
   match, the filter may be ignored or rejected.  URI matching is done
   according to the matching rules defined for a particular scheme (SIP
   URI matching rules are defined in RFC 3261 [2]).

   A filter may also be addressed to a domain using the 'domain'
   attribute instead of the 'uri' attribute.  In this case, the filter
   applies to resources in that domain.  A notifier MUST ignore any
   filter using a 'domain' attribute containing a domain for which this
   notifier is not responsible.  The notifier MUST NOT apply such a
   filter to any notification it sends.  Notifiers belonging to the
   domain MUST apply the filter to all notifications it sends for that
   subscription, unless policy dictates otherwise.






Khartabil, et al.           Standards Track                    [Page 10]

RFC 4660          Functional Description of Filtering     September 2006


5.2.2.  Changing Filters within a Dialog

   If a server receives a subscription refresh request with no filters
   specified (empty payload), it assumes that the client does not wish
   to update the filters.  If it receives a subscription refresh with a
   filter containing the 'remove="true"' attribute, as defined in [5],
   the server assumes that the client is removing the filter identified
   by the filter ID.

   If the server receives a subscription refresh request with a filter
   that already exists (i.e., having the same filter ID), it interprets
   it as a replacement of the existing filter.  Replacing a filter by
   changing the filter ID and keeping the resource URI is considered an
   error since this causes the server to assume that two filters are
   placed for the same resource.

5.3.  Notifier Generating of NOTIFY Requests

   Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD
   retain the filter as long as the subscription persists.  The filter
   MAY be incorporated within an existing subscription (in an active
   dialog) by sending a re-SUBSCRIBE that includes the filter in the
   body.

   If the response sent to the SUBSCRIBE was a "202" and the "202" was
   chosen because the filter could not be accepted that time, the NOTIFY
   MAY be used to terminate the subscription if the filter is found
   unacceptable.

   As described in [3], the NOTIFY message MAY contain a body that
   describes the state of the resource.  This body is in one of the
   formats listed in the Accept header field of the SUBSCRIBE, or in the
   package-specific default if the Accept header field is omitted.

   Based on the contents of a filter, the following processing occurs:

   o  A filter with only a <what> element will result in sending the
      requested resource state information in that <what> element
      whenever there is a change in the resource state.

   o  A filter with only a <trigger> element will result in sending all
      resource state information whenever there is a change in the
      resource state that matches the triggers.

   o  A filter with <what> and <trigger> elements will result in sending
      the requested resource state information in that <what> element
      whenever there is a change in the resource state that matches the
      triggers.



Khartabil, et al.           Standards Track                    [Page 11]

RFC 4660          Functional Description of Filtering     September 2006


   When a filter is disabled (by setting the 'enabled' attribute to
   "false"), it means the same thing as the absence of that filter.
   That is, all state and state changes are reported by issuing a
   notification to the subscriber (assuming there are no other filters).

   When a filter is re-enabled (by setting the 'enabled' attribute to
   "true" or by omitting the 'enabled' attribute), the notifier behaves
   as if the filter has just been placed by the SUBSCRIBE request
   enabling it.  Immediate NOTIFY rules, as stated in Section 5.3.1,
   apply.

5.3.1.  Generation of NOTIFY Contents

   If the NOTIFY being sent is the one sent immediately after a 2xx
   response to the original SUBSCRIBE, its contents MUST be populated
   according to the filter <what> element, unless the processing of the
   filters will take too long or the NOTIFY request is following a "202"
   response to the SUBSCRIBE request and is terminating the
   subscription.  In the case that the filter is taking too long to
   process, the NOTIFY request being sent may be empty or may be
   populated with a pre-configured value as authorised to that
   subscriber.  If applying the filter results in no content to be
   delivered, the NOTIFY MUST be sent with empty contents.  If the
   filter contains <trigger> elements, the notifier ignores the trigger
   values when generating the first NOTIFY request.

   The input to the content filter is a package-specific XML document
   (e.g., [7] and [9]) derived according to the package-specific
   specifications, (e.g., [8] and [10]).

   The content is filtered according to the expressions in the <what>
   element of the filter.  The expression indicates the delivered XML
   elements and/or attributes.  Prefixes of the namespaces of the items
   of the XML document to be filtered must be expanded before applying
   the filter to the items.

   The expression directly states the XML elements and attributes to be
   delivered in the NOTIFY, along with their values.  In addition to the
   selected contents, the namespaces of all the selected items are also
   included in the NOTIFY.  The XML elements and/or attributes indicated
   by the expression in the <what> element must be items that the
   subscriber is authorised to see.  If they are not, the notifier
   policy dictates the behaviour of the notifier (which can ignore the
   filter, parts of the filter, or reject the filter completely).
   Implementers need to carefully consider such an implementation
   decision; the subscriber may not be aware of the authorised contents
   and therefore most likely will include a filter requesting
   unauthorised contents.  It is therefore RECOMMENDED that notifiers



Khartabil, et al.           Standards Track                    [Page 12]

RFC 4660          Functional Description of Filtering     September 2006


   just ignore the parts of the filter that are requesting unauthorised
   info (i.e., the filter in the <filter> element where the unauthorised
   contents are requested is ignored).  If polite blocking is used by
   the notifier, the notifier may choose to deliver notifications
   containing bogus information in the unauthorised elements or
   attributes and applying the filter afterwards.

   The resultant XML document MUST be well formed and valid according to
   the XML schema.  This means that all mandatory elements and
   attributes, along with their values, MUST be included in the XML
   document regardless of the expression.  In other words, if the result
   of applying a filter on an XML document is a non-valid XML document,
   the notifier MUST add elements and attributes, along with their
   values, from the original XML document into the newly formulated one
   in order for it to be valid.

5.3.2.  Handling of Notification Triggering Rules