返回首页

RFC 4661 - An Extensible Markup Language (XML)-Based Format

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroupH.Khartabil RequestforComments:4661 Telio Category:StandardsTrackE.Leppanen M.Lonnfors J.Costa-Requena Nokia September2006 AnExtensibleMarkupLanguage(XML)-BasedFormatfor EventNotificationFiltering StatusofThisMemo Thisdocumentspeci
  Network Working Group                                       H. Khartabil
Request for Comments: 4661                                            Telio
Category: Standards Track                                    E. Leppanen
                                                                             M. Lonnfors
                                                                      J. Costa-Requena
                                                                                      Nokia
                                                                        September 2006

          An Extensible Markup Language (XML)-Based Format for
                      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 a state of a resource.  The document does not describe
   a mechanism whereby filtering of event notification information can
   be achieved.  Filtering is a mechanism for defining the preferred
   notification information to be delivered and for specifying triggers
   that cause that information to be delivered.  In order to enable
   this, a format is needed to enable the subscriber to describe the
   state changes of a resource that cause notifications to be sent to it
   and what those notifications are to contain.  This document presents
   a format in the form of an XML document.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Structure of XML-Encoded Simple-Filter . . . . . . . . . . . .  4
       3.1.  MIME Type for Simple-Filter Document . . . . . . . . . .  4
       3.2.  The <filter-set> Root Element  . . . . . . . . . . . . .  4
       3.3.  The <ns-bindings> Element  . . . . . . . . . . . . . . .  4
       3.4.  The <filter> Element . . . . . . . . . . . . . . . . . .  5
       3.5.  The <what> Element . . . . . . . . . . . . . . . . . . .  6
             3.5.1.  The <include> Element  . . . . . . . . . . . . .  6
             3.5.2.  The <exclude> Element  . . . . . . . . . . . . .  7
             3.5.3.  The ’type’ Attribute . . . . . . . . . . . . . .  7
       3.6.  The <trigger> Element  . . . . . . . . . . . . . . . . .  8
             3.6.1.  The <changed> Element  . . . . . . . . . . . . .  8
             3.6.2.  The <added> Element  . . . . . . . . . . . . . .  9
             3.6.3.  The <removed> Element  . . . . . . . . . . . . . 10
   4.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 10
   5.  Syntax for Referencing XML Items and Making Logical
       Expressions  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       6.1.  Filter Criteria Using <what> Element . . . . . . . . . . 12
       6.2.  Filter Criteria Using <trigger> Element  . . . . . . . . 13
       6.3.  Filter Criteria Using <what> and <trigger> Elements  . . 13
       6.4.  Content Filter Using Namespaces  . . . . . . . . . . . . 14
       6.5.  Content Filter Using Only <include> Elements . . . . . . 14
       6.6.  Two Content Filters as Filter Criteria . . . . . . . . . 15
   7.  XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
       9.1.  application/simple-filter+xml MIME TYPE  . . . . . . . . 19
       9.2.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 20
       9.3.  Schema Registration  . . . . . . . . . . . . . . . . . . 20
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       11.1. Normative References . . . . . . . . . . . . . . . . . . 20
       11.2. Informative References . . . . . . . . . . . . . . . . . 21

1.  Introduction

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

   Filtering is a mechanism for defining the preferred notification
   information, referred to as content, to be delivered and for
   specifying the rules for when that information should be delivered.

   The filtering mechanism is expected to be particularly valuable and
   primarily applicable 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.

   The structure of the filter criteria is described using the XML
   schema.  The filter criteria is presented as an XML document.  The
   XML document contains the user’s preference as to when notifications
   are to be sent to it and what they are to contain.  The scope of the
   "when" part is triggering.

   The triggering is defined as enabling a subscriber to specify
   triggering rules for notifications where the criteria are based on
   changes of the event package [2] specific state information, e.g.,
   for the presence information document [15], the change in the value
   of the <status> element.

   The functionality of the filtering regarding the SIP event
   notifications is specified in [3].

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.

   Throughout the document, the "resulting XML document" refers to the
   final XML document that carries state information to be delivered to
   the subscriber after the filters have been applied to it.

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

3.  Structure of XML-Encoded Simple-Filter

   A simple-filter is an XML document [8] that MUST be well formed and
   MUST be valid according to schemas, including extension schemas,
   available to the validater, and applicable to the XML document.  The
   simple-filter documents MUST be based on XML 1.0 and MUST be encoded
   using UTF-8.

   The namespace identifier for elements defined by this specification
   is a URN [5], which uses the namespace identifier ’ietf’ defined by
   [6] and extended by [4].  This urn is:
   urn:ietf:params:xml:ns:simple-filter.

   This namespace declaration indicates the namespace on which the
   filter criteria are based.

3.1.  MIME Type for Simple-Filter Document

   The MIME type for the simple-filter document is "application/
   simple-filter+xml".  Any transport protocol (SIP [12], for example)
   used to carry the filters that also carries payload type information
   MUST identify the payload as MIME type
   "application/simple-filter+xml" (for example, a Content-Type header
   field).

3.2.  The <filter-set> Root Element

   The root element of the filter criteria is <filter-set>.

   The <filter-set> element contains the namespace definition mentioned
   above.  With the optional ’package’ attribute, it is possible to
   define the package to which the filter criteria is applied.  This
   might be especially useful in cases where the XML document containing
   the filter criteria is separated from the events that make use of it
   or from the protocol that usually carries it.

   The <filter-set> element may contain one <ns-bindings> element.

   The <filter-set> element contains one or more <filter> elements.

3.3.  The <ns-bindings> Element

   The <ns-bindings> element is used to bind namespaces to local
   prefixes used in expressions that select elements or attributes using

   the syntax in Section 5.  Those prefixes apply to the <include>,
   <exclude>, <changed>, <added>, and <removed> elements.

   The <ns-bindings> element contains one or more <ns-binding> elements.
   Each <ns-binding> element has a ’prefix’ attribute.  The value of the
   ’prefix’ attribute is a prefix used to qualify the elements pointed
   to by the expression.  The <ns-binding> element also has a ’urn’
   attribute that identifies the namespace that the prefix represents.

3.4.  The <filter> Element

   The <filter> element is used to specify the content of an individual
   filter.

   The <filter> element has an ’id’ attribute.  The value of the ’id’
   attribute MUST be unique within the <filter-set> element.  The
   <filter> MAY have a ’uri’ attribute.  The value of the ’uri’
   attribute is the URI of the resource to which the filter applies.
   The <filter> MAY have a ’domain’ attribute.  The value of the
   ’domain’ attribute is the domain of the resources to which the filter
   applies.  The ’uri’ attribute and the ’domain’ attribute MUST NOT
   appear together in the <filter>.

   The URI of the resource is useful in cases where the ’event list’
   extension [17] is used with a package.  Since a subscription to an
   event package may be addressed to an event list, the ’uri’ attribute
   allows the subscriber to define a filter specific to an individual
   resource within that list.  That resource may be another list.  The
   ’uri’ attribute may, of course, carry the URI of the list itself.  If
   the <filter> does not contain the ’uri’ attribute, the filter applies
   to the resource identified in the subscription request.

   The ’domain’ attribute carries a domain.  In this case, the filter
   applies to resources whose URI has a domain part matching that
   domain.  This can be used when a subscription is for a resource that
   is an event list with many resources from differing domains.

   URI matching is done according to the matching rules defined for a
   particular scheme.  When matching domains, the user part of the URI
   is ignored for matching purposes.

   The <filter> MAY have a ’remove’ attribute that together with the
   ’id’ attribute indicates the existing filter to be removed.  The
   value of the ’remove’ attribute is of the type "Boolean".  The
   default value is "false".

   The <filter> MAY have an ’enabled’ attribute that indicates whether a
   filter is enabled or disabled.  The value of the ’enabled’ attribute
   is of the type "Boolean".  The default value is "true".

   The <filter> element MAY contain a <what> element and MAY contain one
   or more <trigger> elements, but it MUST contain either the <what>
   element or the <trigger> element when the filter is being enabled for
   the first time.  When a filter is disabled by setting the ’enabled’
   attribute to "false", the <what> and <trigger> elements MAY be
   omitted.  Similarly, when a filter is re-enabled by setting the
   ’enabled’ attribute to "true", the <what> and <trigger> elements MAY
   be omitted.

   Filter contents can be changed by changing the contents in the <what>
   and <trigger> elements and maintaining the value of the filter ’id’
   attribute.

3.5.  The <what> Element

   The <what> element is used to specify the content to be delivered to
   the user.  It does not specify the exact content but the rules that
   are used to construct that information.

   The <what> element may contain one or more <include> elements and one
   or more <exclude> elements.  When more than one <include> element has
   been defined, the results are additive.  That is, each <include>
   element adds an element or attribute to the resulting XML document.
   When more than one <exclude> element has been defined, each <exclude>
   element value depletes the contents of the resulting XML document.

3.5.1.  The <include> Element

   The <include> element is used to select the content to be delivered.
   Its value can identify an XML element, an attribute, or a namespace
   of an XML document to be filtered.  This is indicated using the
   ’type’ attribute.

   Note that the resulting XML document MUST be valid.  Therefore, in
   addition to including the elements identified with the <include>
   element value, all other mandatory XML elements and/or attributes
   must be incorporated in the resulting XML document in order to make
   it valid.  This, in practice, means that a subscriber defining a
   filter only needs to <include> optional elements and/or attributes,
   but may <include> mandatory elements and/or attributes as well.
   There are also cases where a filter selects an attribute that belongs
   to an optional element.  In this case, the optional element needs to
   appear in the resulting XML document.

   The syntax defined in Section 5 (see the definition of "selection")
   MUST be used.  The following example selects the <basic> element
   defined in the PIDF [13].  This results in the selection of the
   <basic> element as well as all the ancestors, i.e., <status> and
   <tuple>.

   <include type="xpath">/presence/tuple/status/basic</include>.

3.5.2.  The <exclude> Element

   The <exclude> element is used to define exceptions to the set of XML
   elements and/or attributes selected by the <include> elements.  Thus,
   XML elements (including their lower-level "child" elements) and/or
   attributes defined by the <exclude> element are not delivered.  This
   is most useful when an <include> element identifies a namespace.

   The <exclude> element has the optional ’type’ attribute (see the
   definition of the ’type’ in Section 3.5.3).

   Note that the resulting XML document MUST be valid.  Therefore, if
   the step in applying the <exclude> element value to an XML document
   results in an invalid document according to the schema, that step
   MUST be reversed, resulting in the elements and/or attributes being
   re-introduced into the resulting XML document with their previous
   values in order to make it valid.  This, in practice, means that a
   subscriber defining a filter only needs to <exclude> optional
   elements and/or attributes, but SHOULD NOT <exclude> mandatory
   elements and/or attributes.

   The syntax MUST follow Section 5.

3.5.3.  The ’type’ Attribute

   The ’type’ attribute is used to describe the value of the <include>
   and <exclude> elements.  The following values are pre-defined:
   "xpath" and "namespace".  The ’type’ attribute is optional, and, if
   omitted, the default value is "xpath".

   The "xpath" value is used when the <include> or <exclude> element
   contains a value following the syntax in Section 5 that selects an
   element or an attribute.

   The "namespace" value is used when the <include> or <exclude> element
   contains a value of a namespace.  The value is the URI of the
   namespace.  The resulting XML document is comprised of the elements
   defined within the namespace.

3.6.  The <trigger> Element

   The <trigger> element is used to identify the package-specific
   changes that a resource has to encounter before the content is
   delivered to the subscriber.  It can appear more than once in a
   <filter> element.  Multiple appearances of this element denote the
   "OR" operation.  This means that updates to a resource that satisfy
   any of the <trigger> elements criteria constitute the content to be
   delivered.

   The <trigger> element MAY contain the <changed>, <added>, or
   <removed> elements, but it MUST contain at least one of the three
   elements.  Any combination of the 3 elements is possible.  Multiple
   appearances of those elements within a <trigger> element denotes the
   "AND" operation.  This means that updates to a resource that satisfy
   ALL of the <changed>, <added>, and <removed> elements’ criteria
   within the <trigger> element constitute the content to be delivered.

3.6.1.  The <changed> Element

   The <changed> element is used to identify the XML element or
   attribute, from the package-specific XML document, whose value MUST
   change from that of the "previous XML document", in order to activate
   the trigger and cause the content to be delivered.  Previous XML
   document" in this context refers to the raw version of the most
   recent XML document that was sent to the subscriber, before the
   filters were applied to it.  The XML element or attribute MUST be
   expressed using the syntax defined in Section 5 for the "reference"
   ABNF.

   The <changed> element MAY contain the ’from’ attribute, the ’to’
   attribute, the ’by’ attribute, or any combination of the three.  The
   absence of all of those attributes means a change of any sort to the
   value of the element or attribute activates the trigger.  An update
   to the element or attribute value with an identical value is not a
   change.

   Comparison of a change is done according to the element or
   attribute’s lexical rules.

3.6.1.1.  The ’from’ Attribute

   A trigger is active when the XML element or attribute identified with
   the <changed> element has changed from the value indicated by this
   attribute to a different value.

3.6.1.2.  The ’to’ Attribute

   A trigger is active when the XML element or attribute identified with
   the <changed> element has changed to the value indicated by this
   attribute from a different value.

3.6.1.3.  The ’by’ Attribute

   A trigger is active when the XML element or attribute identified with
   the <changed> element has changed by at least the amount indicated by
   this attribute from a different value.  That is, the ’by’ attribute
   applies only to numerical values and indicates a delta with respect
   to the current value that an attribute or element (identified in the
   <changed> element) needs to change before it is selected.  For
   example, if the ’by’ attribute is set to 2 and the current value of
   the element/attribute is 6, the element/attribute is selected when it
   reaches (or exceeds) the value 8 or when it decreases to 4 or a lower
   value.

3.6.1.4.  Combination of Attributes

   Any combination of the ’from’, ’to’, and ’by’ attributes in the
   <changed> element is possible.  For example, if the ’from’ attribute
   is combined with the ’to’ attribute, it is interpreted to mean that
   the trigger is active when the XML element or attribute identified
   with the <changed> element has changed from the ’from’ value to the
   ’to’ value.  Note that if the ’by’ attribute is used in combination
   with the other attributes, the other attribute types MUST match the
   ’by’ type of decimal.

3.6.2.  The <added> Element

   The <added> element triggers content delivery when the XML element it
   identifies has been added to the document being filtered (that is,
   this instance of that element appears in the current document, but
   not in the previous document).  It can be used, for example, to learn
   of new services and/or capabilities subscribed to by the user, or
   services and/or capabilities that the user has now allowed the
   subscriber to see.  The XML element or attribute MUST be expressed
   using the syntax defined in Section 5 for the "reference" ABNF.

   Note that if a filter includes both the content filter (<what>) part
   and the <added> element, then the definitions of the <what> part
   SHOULD also cover the added elements.  Otherwise, the content is
   delivered without the items defined in the <added> element.

3.6.3.  The <removed> Element

   The <removed> element triggers content delivery when the XML element
   it identifies has been removed from the document being filtered (that
   is, this instance of that element appeared in the previous document,
   but not in this document).  The XML element or attribute MUST be
   expressed using the syntax defined in Section 5 for the "reference"
   ABNF.

4.  XML Schema Extensibility

   The simple-filter document is meant to be extended.  An extension
   takes place by defining a new set of elements in a new namespace,
   governed by a new schema.  Every extension MUST have an appropriate
   XML namespace assigned to it.  The XML namespace of the extension
   MUST be different from the namespaces defined in this specification.
   The extension MUST NOT change the syntax or semantics of the schemas
   defined in this document.  All XML tags and attributes that are part
   of the extension MUST be appropriately qualified so as to place them
   within that namespace and MUST be designed such that receivers can
   safely ignore such extensions.

   This specification defines explicit places where new elements or
   attributes from an extension can be placed.  These are explicitly
   indicated in the schemas by the <any> and <anyAttribute> elements.
   Extensions to this specification MUST specify where their elements
   can be placed within the document.

   As a result, a document that contains extensions will require
   multiple schemas in order to determine its validity - a schema
   defined in this document, along with those defined by extensions
   present in the document.  Because extensions occur by adding new
   elements and attributes governed by new schemas, the schemas defined
   in this document are fixed and would only be changed by a revision to
   this specification.  Such a revision, should it take place, would
   endeavor to allow documents compliant to the previous schema to
   remain compliant to the new one.  As a result, the schemas defined
   here don’t provide explicit schema versions, as this is not expected
   to be needed.

5.  Syntax for Referencing XML Items and Making Logical Expressions

   The ABNF [10] is used to describe the syntax for the expressions.
   The syntax is defined to be XPATH [9] compatible but has only a
   restricted set of capabilities of the XPATH.  More information about
   the meaning of the items of the syntax can be found in [9].  The
   "abbreviated syntax" of the "node test" is used in the references
   ("reference").  The expression in the syntax relates to the

   predicate, comparison, and logical expressions of the XPATH.  If an
   XPATH expression evaluates to more than one element at a certain
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容