返回首页

RFC 4660 - Functional Description of Event Notification Filt

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroupH.Khartabil RequestforComments:4660 Telio Category:StandardsTrackE.Leppanen M.Lonnfors J.Costa-Requena Nokia September2006 FunctionalDescriptionofEventNotificationFiltering StatusofThisMemo ThisdocumentspecifiesanInternetstandardst
  Network Working Group                                       H. Khartabil
Request for Comments: 4660                                            Telio
Category: Standards Track                                    E. Leppanen
                                                                             M. Lonnfors
                                                                    J. Costa-Requena
                                                                                     Nokia
                                                                     September 2006

         Functional Description of Event Notification Filtering

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The SIP event notification framework describes the usage of the
   Session Initiation Protocol (SIP) for subscriptions and notifications
   of changes to the state of a resource.  The document does not
   describe a mechanism whereby filtering of event notification
   information can be achieved.

   This document describes the operations a subscriber performs in order
   to put filtering rules associated with a subscription to event
   notification information in place.  The handling, by the subscriber,
   of responses to subscriptions carrying filtering rules and the
   handling of notifications with filtering rules applied to them are
   also described.  Furthermore, the document conveys how the notifier
   behaves when receiving such filtering rules and how a notification is
   constructed.

Table of Contents

   1. Introduction ....................................................3
   2. Conventions .....................................................3
   3. Client Operation ................................................4
      3.1. Transport Mechanism ........................................4
      3.2. SUBSCRIBE Bodies ...........................................4
      3.3. Subscriber Generating of SUBSCRIBE Requests ................4
           3.3.1. Defining the Filtering Rules ........................4
           3.3.2. Request-URI vs. Filter URI ..........................5
           3.3.3. Changing Filters within a Dialog ....................5
           3.3.4. Subscriber Interpreting of SIP Responses ............6
      3.4. Subscriber Processing of NOTIFY Requests ...................6
   4. Resource List Server Behaviour ..................................7
      4.1. Request-URI vs. Filter URI .................................7
      4.2. Changing Filters within a Dialog ...........................9
   5. Server Operation ................................................9
      5.1. NOTIFY Bodies ..............................................9
      5.2. Notifier Processing of SUBSCRIBE Requests ..................9
           5.2.1. Request-URI vs. Filter URI .........................10
           5.2.2. Changing Filters within a Dialog ...................11
      5.3. Notifier Generating of NOTIFY Requests ....................11
           5.3.1. Generation of NOTIFY Contents ......................12
           5.3.2. Handling of Notification Triggering Rules ..........13
      5.4. Handling Abnormal Cases ...................................13
   6. XML Document Validation ........................................14
   7. Examples .......................................................14
      7.1. Presence Specific Examples ................................14
           7.1.1. Subscriber Requests Messaging-Related Information ..15
           7.1.2. Subscriber Fetches Information about "Open"
                  Communication Means ................................16
           7.1.3. Subscriber Requests Notifications When
                  Presentity’s Status Changes ........................18
      7.2. Watcher Information Specific Examples .....................21
           7.2.1. Watcher Subscriber Makes Subscription to
                  Get All the Information about Active Watchers ......22
           7.2.2. Watcher Subscriber Requests Information of
                  Watchers with Specific Subscription Duration
                  Conditions .........................................23
           7.2.3. Watcher Subscriber Requests Specific
                  Watcher Info on Specific Triggers ..................24
   8. Security Considerations ........................................27
   9. IANA Considerations ............................................28
   10. Acknowledgements ..............................................28
   11. References ....................................................28
      11.1. Normative References .....................................28
      11.2. Informative References ...................................28

1.  Introduction

   SIP event notification is described in [3].  It defines a general
   framework for sending subscriptions and receiving notifications in
   SIP-based systems.  It introduces the concept of event packages,
   which are concrete applications of the general event framework to a
   specific usage of events.

   Filtering is a mechanism for controlling the content of event
   notifications.  Additionally, the subscriber may specify the rules
   for when a notification should be sent to it.  The filtering
   mechanism is expected to be particularly valuable to users of mobile
   wireless access devices.  The characteristics of the devices
   typically include high latency, low bandwidth, low data processing
   capabilities, small display, and limited battery power.  Such devices
   can benefit from the ability to filter the amount of information
   generated at the source of the event notification.  However,
   implementers need to be aware of the computational burden on the
   source of the event notification.  This is discussed further in
   Section 8.

   It is stated in [3] that the notifier may send a NOTIFY at any time,
   but typically it is sent when the state of the resource changes.  It
   also states that the notifications would contain the complete and
   current state of the resource authorized for a certain subscriber to
   see.  The format of such resource state information is package
   specific.  In this memo, we assume that the NOTIFY for any package
   contains an XML document.

   This document, together with [5], presents a mechanism for filtering
   whereby a subscriber describes its preference of when notifications
   are to be sent to it and what they are to contain.  It also describes
   how the notifier functions when generating notifications by taking
   into account filters and default functionality of the package/
   service.

   The XML format for defining the filter is described in [5].

2.  Conventions

   In this document, the key words ’MUST’, ’MUST NOT’, ’REQUIRED’,
   ’SHALL’, ’SHALL NOT’, ’SHOULD’, ’SHOULD NOT’, ’RECOMMENDED’, ’MAY’,
   and ’OPTIONAL’ are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

   "Content" refers to the XML document that appears in a notification
   reflecting the state of a resource.

3.  Client Operation

3.1.  Transport Mechanism

   Transportation of the filter to the server is achieved by inserting
   the XML document, as defined in [5], in the body of the SUBSCRIBE
   request.  Alternatively, the XML document can be uploaded to the
   server using means outside the scope of this document.

3.2.  SUBSCRIBE Bodies

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

3.3.  Subscriber Generating of SUBSCRIBE Requests

   This section presents additional functionality required from the
   subscriber when filters are used in the bodies of the SUBSCRIBE
   requests.  Normal operations of services (e.g., as defined in [8],
   [10], and [4]) are otherwise followed.

   As defined in [3], the SUBSCRIBE message MAY contain a body.  This
   body would carry filtering information.  Honouring those filters is
   at the discretion of the notifier and might depend on local policies.

   No content in the body of a SUBSCRIBE indicates to the notifier that
   no filter is being requested, so the notifier is instructed to send
   all the NOTIFY requests using the notifier’s own or service-specific
   policy.  Note that, for example, in the list case [4], the filter
   might have been uploaded to the server beforehand (by means outside
   the scope of this document).

   If the body of the SUBSCRIBE includes the filter, the body MUST be of
   the MIME-Type ’application/simple-filter+xml’.

3.3.1.  Defining the Filtering Rules

   Multiple filters MAY be included in one SUBSCRIBE.  This is achieved
   by including multiple <filter> elements in the filter [5].  Each
   <filter> element may include a ’uri’ attribute.

   A SUBSCRIBE request destined to a list URI [4] MAY include multiple
   filters specific to individual resources.  This is achieved by
   including multiple <filter> elements with different URIs of resources
   in each of those elements.  This resource specific resource-specific
   filter are processed first before any list specific list-specific
   filter, if any.  The list specific list-specific filter may or may
   not include a URI.

   Furthermore, regardless of whether the SUBSCRIBE is destined to a
   list URI, there can only be one filter applicable to a single
   resource or domain within a single SUBSCRIBE.  That is, each filter
   within a subscription MUST uniquely identify one resource or one
   domain.

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

3.3.2.  Request-URI vs. Filter URI

   The URI in the filter defines the target resource.  For example, in
   the Presence service case, it is the presentity’s presence
   information to which the filter is applied.  The subscriber MAY
   choose 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 define
   a filter URI.  If the Request-URI is a list URI [4], the filter URI
   MUST be the list URI, a sub-list URI, or resource whose URI is one of
   the URIs that result from a lookup, by a Resource List Server (RLS),
   on the Request-URI.  If it is not, the filter may be ignored or may
   be 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.  This can be used when a
   subscription is for a resource that is an event list with many
   resources from differing domains.  If an individual resource-specific
   filter is present along with the domain filter, this
   resource-specific filter overrides any domain-specific filter, if
   any.

3.3.3.  Changing Filters within a Dialog

   The subscriber MAY reset or change the filter by re-issuing a new
   SUBSCRIBE request within the existing dialog.  A SUBSCRIBE within the
   exiting dialog that does not contain a filter is assumed to maintain
   existing filters.  This means that filters are persistent within a
   dialog and are only explicitly removed.

   A subscriber requiring removal of a filter may do so by using the
   ’remove="true"’ attribute, as defined in [5].

   In the case where the URI in the filter is that of a list, a
   subscriber may override the existing filter with a filter for an
   individual resource that is part of the list subscribed to earlier by

   issuing a new SUBSCRIBE within the existing dialog and including a
   filter, specific for that individual resource, using a new filter ID.
   The new filter need not include the original filter since a filter is
   only removed in the manner indicated above.

   A filter is replaced by the subscriber re-issuing the filter using
   the same filter ID and replacing the contents of the 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.

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

3.3.4.  Subscriber Interpreting of SIP Responses

   The SUBSCRIBE request will be confirmed with a final response.  A
   200-class response indicates that the subscription has been accepted
   and that a NOTIFY will be sent immediately.  A "200" response
   indicates that the subscription has been accepted and that the filter
   is accepted.  A "202" response merely indicates that the subscription
   has been understood, that the content type has been accepted, and
   that authorization may or may not have been granted.  A "202"
   response also indicates that the filter has not been accepted yet.
   The acceptance of the filter MAY arrive in a subsequent NOTIFY.

   A non-200 class final response indicates that no subscription or
   dialog has been created, and no subsequent NOTIFY message will be
   sent.  All non-200 class final responses have the same meanings and
   handling as described in [2] and [3].

   Specifically, a "415" response indicates that the MIME type
   ’application/simple-filter+xml’ is not understood by the notifier.  A
   "488" response indicates that the content type (filter) is understood
   but some aspects of it were either not understood or not accepted.

3.4.  Subscriber Processing of NOTIFY Requests

   If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that
   follows MAY contain a body that describes the present state of the
   resource after the filters have been applied.

   If the NOTIFY indicates that a subscription has been terminated [3],
   the subscription is assumed to be terminated.  Behaviour in such
   events is also described in [3].

   If the subscription is indicated as active, NOTIFY requests are
   handled as described in package-specific documents and in [3].

4.  Resource List Server Behaviour

   The Resource List Server is defined in [4].  This section describes
   how such an entity behaves in the presence of a filter in a
   subscription to a list.

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:mybuddies@example.com", where
   "bob@example.com" is a resource belonging to that list, and the URI
   in a filter is "sip:bob@example.com", the filter specific for Bob is
   extracted and placed in the body of the SUBSCRIBE sent to
   "bob@example.com".

   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.

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

   List1 (list1@example.com) on RLS1 has: bob@example.com

   list2@biloxi.com

   List2 on RLS2 has: alice@biloxi.com sarah@example.com
   (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 sarah@example.com
   and the other for alice@biloxi.com):

   SUBSCRIBE sip:List1@example.com 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:sarah@example.com">
       <what>
         <include type="namespace">
           urn:ietf:params:xml:ns:pidf</include>
         <exclude>
           //pidf:tuple/pidf:note</exclude>
       </what>
     </filter>
     <filter id="8439" uri="sip:alice@biloxi.com">
       <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 alice@biloxi.com is propagated since biloxi.com is
   not under the administrative domain of RLS1.  The filter to
   sarah@example.com 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]).

   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.

   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.

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.
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容