[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SIMPLE                                                      H. Khartabil
Internet-Draft                                               M. Lonnfors
Expires: April 23, 2004                                 J. Costa-Requena
                                                             E. Leppanen
                                                                   Nokia
                                                        October 24, 2003


       An Extensible Markup Language (XML) Based Format for Event
                         Notification Filtering
                draft-khartabil-simple-filter-format-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 23, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

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 of how filtering of event notification information can be
   achieved.

   In order to enable this, a format is needed to enable the subscriber
   to choose when notifications are to be sent to it and what they are
   to contain. This document presents a solution in the form of an XML



Khartabil, et al.        Expires April 23, 2004                 [Page 1]

Internet-Draft       XML Based Format for Filtering         October 2003


   document format.

Table of Contents

   1.      Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Structure of XML-Encoded Filter Criteria . . . . . . . . .  3
   3.1     The <filter-set> Root Element  . . . . . . . . . . . . . .  4
   3.2     The <filter> Element . . . . . . . . . . . . . . . . . . .  4
   3.3     The <what> Element . . . . . . . . . . . . . . . . . . . .  5
   3.3.1   The <condition> Element  . . . . . . . . . . . . . . . . .  5
   3.3.1.1 The "base-element" Attribute . . . . . . . . . . . . . . .  6
   3.3.2   The <include> Element  . . . . . . . . . . . . . . . . . .  6
   3.3.2.1 The "type" Attribute . . . . . . . . . . . . . . . . . . .  7
   3.3.2.2 The "level" Attribute  . . . . . . . . . . . . . . . . . .  7
   3.3.3   The <exclude> Element  . . . . . . . . . . . . . . . . . .  8
   3.4     The <trigger> Element  . . . . . . . . . . . . . . . . . .  8
   3.4.1   The <changed> Element  . . . . . . . . . . . . . . . . . .  8
   3.4.1.1 The "changed-from" Attribute . . . . . . . . . . . . . . .  9
   3.4.1.2 The "changed-to" Attribute . . . . . . . . . . . . . . . .  9
   3.4.1.3 The "changed-by" Attribute . . . . . . . . . . . . . . . .  9
   3.4.1.4 Combination of Attributes  . . . . . . . . . . . . . . . .  9
   3.4.2   The <added> Element  . . . . . . . . . . . . . . . . . . .  9
   3.4.3   The <removed> Element  . . . . . . . . . . . . . . . . . . 10
   4.      Syntax for Referencing XML Items and Making Logical
           Expressions  . . . . . . . . . . . . . . . . . . . . . . . 10
   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.      Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.1     Filter Criteria Using <what> Element . . . . . . . . . . . 11
   6.2     Filter Criteria Using <trigger> Element  . . . . . . . . . 12
   6.3     Filter Criteria Using <what> and <trigger> Elements  . . . 12
   6.4     Content Filter Using Namespaces  . . . . . . . . . . . . . 13
   6.5     Content Filter Using Only <Include> Elements . . . . . . . 13
   6.6     Two Content Filters as Filter Criteria . . . . . . . . . . 14
   7.      XML Schema for Filter Criteria . . . . . . . . . . . . . . 15
   8.      Security Requirements  . . . . . . . . . . . . . . . . . . 17
   9.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18
   10.     Changes from version 00  . . . . . . . . . . . . . . . . . 18
           References . . . . . . . . . . . . . . . . . . . . . . . . 18
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 20
           Intellectual Property and Copyright Statements . . . . . . 21










Khartabil, et al.        Expires April 23, 2004                 [Page 2]

Internet-Draft       XML Based Format for Filtering         October 2003


1. 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.

2. Introduction

   Filtering is a mechanism for defining the preferred content to be
   delivered and for specifying the rules for when the content should be
   delivered. See requirements in [9] and [10].

   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.

   The SIP event notification framework [6] 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 of how filtering of event notification information can be
   achieved.

   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 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 package specific state information, e.g., for the
   presence information document [5] the change in the value of the
   <status> element.

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

3. Structure of XML-Encoded Filter Criteria

   The filter criteria is an XML document [16] that MUST be well-formed
   and MUST be valid. The filter criteria XML documents MUST have the
   XML declaration and it SHOULD contain an encoding declaration in the
   XML declaration, for example; "<?XML version='1.0'
   encoding='UTF-8'?>". This specification makes use of XML namespaces



Khartabil, et al.        Expires April 23, 2004                 [Page 3]

Internet-Draft       XML Based Format for Filtering         October 2003


   for identifying the XML schema of the filter criteria instance
   documents and document fragments.

   The namespace identifier for elements defined by this specification
   is a URN [13], using the namespace identifier 'ietf' defined by [14]
   and extended by [12]. This urn is:
   urn:ietf:params:xml:ns:simple-filter+xml.

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

3.1 The <filter-set> Root Element

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

   The <filter-set> element MUST contain 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 makes use of it
   or from the protocol that usually carries it.

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

3.2 The <filter> Element

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

   The <filter> MUST have an 'id' attribute. The value of the 'id'
   attribute MUST be unique within the <filter-set> element. The
   <filter> MAY have an 'uri' attribute. The value of the 'uri'
   attribute is the URI of the resource which information is requested
   for.

   The URI of the resource is useful in cases where the 'eventlist'
   extension [7] is used with a package and different filters are
   defined for one or more members of the list. The 'uri' attribute in
   the <filter> element identifies either the URI of the list (or nested
   sub-list) or the URI of an individual member within the list to whom
   that specific filter applies. If the <filter> does not contain the
   'uri' attribute, the filter applies to all the members in the list
   unless a member of the list has its own filter attributed by the
   'uri' attribute.

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



Khartabil, et al.        Expires April 23, 2004                 [Page 4]

Internet-Draft       XML Based Format for Filtering         October 2003


   is 'false'.

   The <filter> element MAY contain a <what> element and MAY contain one
   or more <trigger> elements, but MUST contain either the <what>
   element or the <trigger> element.

3.3 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 a <condition> element, one or more
   <include> elements and one or more <exclude> elements. However, the
   <what> element MUST contain at least one <include> element.

3.3.1 The <condition> Element

   The <condition> element is used to select "base elements" using
   values of XML elements or XML attributes related to the base
   elements. The base element is defined by a mandatory XML attribute
   ("base-element"). The value of the <condition> element consists of
   comparison and logical expressions that has a Boolean outcome. The
   syntax for the expressions is defined in Section 4 (see the
   definition of the "expression"). The base element is selected if the
   expression is positive.

   The following example selects the tuples that have a <basic> element
   of the value 'open':

   <condition base-element="//tuple">status/basic="open"</condition>.

   A couple of example expressions are listed below:


   o  Comparison expressions using XML elements:

      *  /status/basic="open"

      *  */basic="open"

   o  Comparison expressions using XML attributes:

      *  @duration-subscribed<500

      *  @event="rejected"





Khartabil, et al.        Expires April 23, 2004                 [Page 5]

Internet-Draft       XML Based Format for Filtering         October 2003


   o  Logical expressions using values of two XML elements:

      *  status/basic="open" and type="device".


3.3.1.1 The "base-element" Attribute

   The "base-element" attribute defines the base element selected by the
   expression. The "base-element" attribute is used to identify the
   element itself or an ancestor element of the XML element or attribute
   that used in the expression. The syntax of the value of the
   "base-element" is defined in Section 4 (see the definition of the
   "reference").

   Examples of values of the "base-element" attribute are listed as
   follows:

   o  //tuple

   o  /presence/tuple

   o  //*

   o  /*/tuple.


3.3.2 The <include> Element

   The <include> element is used to select the content to be delivered.
   The value of the <include> element depends on the "type" attribute.
   The value is allowed to be a reference to an XML element or
   attribute, a namespace or another value related to the "type"
   attribute. Another XML attribute in the <include> is "level". The
   optional "level" attribute is used to select elements related to the
   element identified in the body of the <include> element.

   Note that in addition to the content defined using the <include>
   elements also other mandatory XML items may become selected to make
   the resulting XML document valid.

   The following example selects descendants of the <status> element.
   Thus, it selects the <basic> element according to [2].

   <include type="xml-element" level="descendant">//tuple/status</
   include>.

   If both the <condition> and the <include> elements are defined in a
   content filter, the value of the <include> element relates to the



Khartabil, et al.        Expires April 23, 2004                 [Page 6]

Internet-Draft       XML Based Format for Filtering         October 2003


   base element in such a way that the value of the <include> element
   MUST be either the defined base element or one of the lower level
   ("child") elements of the base element.

3.3.2.1 The "type" Attribute

   The "type" attribute is used to describe the value of the <include>
   element. The following values are pre-defined: 'xml-element',
   'namespace' and 'token'. Other values of the "type" attribute may be
   defined later. The "type" attribute is optional, and, if omitted, the
   default value is 'xml-element'.

   The 'xml-element' is used when the <include> element contains a
   reference of an XML element or attribute. Section 4 defines the
   syntax for the reference (see the definitions of the "reference" for
   referencing the XML elements and "attr-reference" for referencing the
   XML attributes).

   Example references are listed as follows:


   o  Referencing XML elements giving the full hierarchical path: /
      presence/tuple/status/basic

   o  Referencing XML elements from any level by its name: //basic

   o  Referencing XML attributes of an XML element: //watcher/
      @duration-subscribed

   o  Referencing XML attributes of any element: //@expiration.


   The "namespace" value is used when the <include> element contains a
   value of a namespace. The value is the URI of the namespace.

   The "token" is used to define the content by a value referring to a
   certain pre-defined set of elements (e.g., elements which are
   semantically close to each other) supported by a entity intepreting
   the filter.

   Example: <include type="token">location</include>.

3.3.2.2 The "level" Attribute

   The "level" attribute is used to select the related elements of the
   element identified in the <include> element, along with the
   identified element itself. The following values are pre-defined:
   'self', 'ancestor' and 'descendant'. If the attribute is omitted the



Khartabil, et al.        Expires April 23, 2004                 [Page 7]

Internet-Draft       XML Based Format for Filtering         October 2003


   default value is 'self'.

   Note that only the 'self' value makes sense to the include
   definitions of the types 'namespace' and 'token'.

   The 'self' value indicates the selection of the given XML element.
   The 'ancestor' value indicates the selection of the parent elements
   of the given XML element. The 'descendant' value indicates the
   selection of the sub-tree ("child elements") of the given XML
   element. The Section 4 defines the syntax for referencing the XML
   element.

3.3.3 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,
   those XML elements (including their lower level "child" elements)
   and/or attributes defined by the <exclude> element are not delivered.
   The <exclude> element has the optional "type" attribute (see the
   definition of the "type" in Section 3.3.2.1).

   The <exclude> element can be used only if one or more <include>
   element(s) have been included in the same content filter.

3.4 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
   document. Multiple appearances of this element denotes 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> element, the <added>
   element or the <removed>, but MUST contain at least one of the three
   elements. Any combination of the 3 elements is possible. Multiple
   appearances of those element 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.4.1 The <changed> Element

   The <changed> element is used to identify the XML element or
   attribute, from the package specific XML document, that must change,
   compared to the previous XML document, in order to activate the
   trigger and cause the content to be delivered. The XML element or



Khartabil, et al.        Expires April 23, 2004                 [Page 8]

Internet-Draft       XML Based Format for Filtering         October 2003


   attribute is indicated using the syntax defined in Section 4 for the
   "reference" and "attr-reference". The indication MUST only point to
   one XML element or attribute.

   The <changed> element MAY contain the "changed-from" attribute,
   "changed-to" attribute, "changed-by" attribute, or any combination of
   the three.

3.4.1.1 The "changed-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.4.1.2 The "changed-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.4.1.3 The "changed-by" Attribute

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

3.4.1.4 Combination of Attributes

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

3.4.2 The <added> Element

   The <added> element is used to trigger the content delivery when the
   XML element or attribute, identified in it, has been added to the new
   XML document in comparison to the previous XML 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 is indicated using the syntax defined in Section 4 for the
   "reference" and "attr-reference".



Khartabil, et al.        Expires April 23, 2004                 [Page 9]

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

3.4.3 The <removed> Element

   The <removed> element is used to trigger the content to be delivered
   when the XML element or attribute, identified in it, has been removed
   from the new XML document in comparison to the previous XML document.
   The XML element or attribute is indicated using the syntax defined in
   Section 4 for the "reference" and "attr-reference".

4. Syntax for Referencing XML Items and Making Logical Expressions

   The ABNF [18] is used to describe the syntax for the references and
   expressions. The syntax is defined to be XPATH [17] 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 [17]. The "abbreviated syntax" of the "node test" is used in the
   references ("reference" and "attr-reference"). The expression in the
   syntax relates to the predicate, comparision and logical expressions
   of the XPATH. The square brackets of predicate expression are left
   out.

   expression = (elem-expr / attr-expr) 1*[oper (elem-expr / attr-expr)]
   elem-expr = (elem-path / ".") compar value
   elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]
   attr-expr = [elem-path "/"] attribute compar value

   reference = "/" 1*("/" / "/*" / ("/" element))
   attr-reference = reference attribute

   oper = "and" / "or"
   compar = "=" / "<" / ">"
   element = [ns] string
   attribute = "@" [ns] string
   ns = string ":"
   string = <any sequence of data supported by XML in names of XML element, and/or attribute or prefixes of namespaces>
   value = <any sequence of data supported by XML as a value of the XML element and/or attribute>


5. IANA Considerations

   A new content type "application/simple-filter+xml" is defined to
   represent an XML MIME for the filter criteria.

   This specification follows the guidelines of RFC3023 [15]

   OPEN ISSUE: IANA registration template must be added later.



Khartabil, et al.        Expires April 23, 2004                [Page 10]

Internet-Draft       XML Based Format for Filtering         October 2003


6. Examples

   The XML Schema for the XML document examples is specified in the
   Section 7.

6.1 Filter Criteria Using <what> Element

   This example shows two ways for defining a content filter where the
   whole content and upper level elements of the tuples of the presence
   information are selected based on a condition defined by a logical
   expression. The condition is: select <class> elements that have a
   value "MMS", "SMS" or "IM".

   The <class> element is defined in [3] as extension to PIDF [2]. The
   first filter definition includes optional elements while the second
   filter definition shows only the minimum set of definitions.

   The first filter definition:

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
                xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"
                package="presence">
         <filter id="mess" uri="sip:presentity@domain.com">
              <what>
                        <condition base-element="//tuple" type="xml-element">rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"
                        </condition>
                        <include level="self" type="xml-element">//tuple</include>
                        <include level="descendant">//tuple</include>
                        <include level="ancestor">//tuple</include>
               </what>
           </filter>
   </filter-set>


   Another alternative definition is presented below. Note that one of
   the <include> elements is omitted which means that it is assumed that
   the data format (PIDF [2]) mandates, e.g., the upper level elements
   of the selected tuples to be delivered.












Khartabil, et al.        Expires April 23, 2004                [Page 11]

Internet-Draft       XML Based Format for Filtering         October 2003


   <?xml version="1.0" encoding="UTF-8"?>
      <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
            <filter id="mess">
                <what>
                  <condition base-element="//tuple">class="IM" or class="SMS" or class="MMS"</condition>
                  <include>//tuple</include>
                  <include level="descendant">//tuple</include>
                </what>
           </filter>
      </filter-set>


6.2 Filter Criteria Using <trigger> Element

   This filter criteria selects the content to be delivered to the
   subscriber when a certain PIDF [2] tuple changes its <basic> status
   from 'CLOSED' to 'OPEN'.

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
        <filter id="open_mean" uri="sip:presentity@domain.com">
           <trigger>
                    <changed changed-from="CLOSED" changed-to="OPEN">/presence/tuple/status/basic</changed>
           </trigger>
        </filter>
   </filter-set>


6.3 Filter Criteria Using <what> and <trigger> Elements

   This filter criteria selects watcher information notifications [8] to
   be sent when the pending subscription status has changed from
   "pending" to "terminated". In the notification, only the watchers
   that have a status of "terminated" and an event of "rejected" are
   included.
















Khartabil, et al.        Expires April 23, 2004                [Page 12]

Internet-Draft       XML Based Format for Filtering         October 2003


   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
                       package="winfo">
         <filter id="filterX" uri="sip:presentity@domain.com">
            <what>
                <condition base-element="//watcher">
                        @status="terminated" and @event="rejected"
                </condition>
                <include>//watcher</include>
                <include level="ancestor">//watcher</include>
            </what>
            <trigger>
                 <changed changed-from="pending" changed-to="terminated">//watcher/@status</changed>
            </trigger>
         </filter>
   </filter-set>


6.4 Content Filter Using Namespaces

   This filter criteria selects XML elements belonging to certain
   namespaces.

   <?xml version="1.0" encoding="UTF-8"?>
        <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
                          package="presence">
           <filter id="filter-PIDF" uri="sip:buddylist@domain.com">
                <what>
                        <include type="namespace"> urn:ietf:params:xml:ns:cpim-pidf
                        </include>
                </what>
               </filter>
        </filter-set>


6.5 Content Filter Using Only <Include> Elements

   This filter criteria selects certain XML elements.













Khartabil, et al.        Expires April 23, 2004                [Page 13]

Internet-Draft       XML Based Format for Filtering         October 2003


   <?xml version="1.0" encoding="UTF-8"?>
        <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
                                package="presence">
           <filter id="filter-abc">
                <what>
                   <include>//status</include>
                   <include>//icon</include>
                   <include>/presence/tuple/note</include>
                   <include>//vcard</include>
                </what>
           </filter>
        </filter-set>


6.6 Two Content Filters as Filter Criteria

   This filter criteria defines two content filters: the first one to be
   used for a list of "buddies" and the second one to get more
   information about one of the friends. The PIDF extension elements
   defined in [4] are filtered out.

   <?xml version="1.0" encoding="UTF-8"?>
      <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
        xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"
        xmlns:cip="urn:ietf:params:xml:ns:pidf:cipid">

            <filter id="8439" uri="sip:buddies@domain.com">
                <what>
                        <condition base-element="//tuple">rpid:type="service" or rpid:type="device"
                        </condition>
                        <include>//contact</include>
                        <include>//status</include>
                        <include level="descendant">//status</include>
                        <include level="ancestor">//status</include>
                </what>
            </filter>

            <filter id="999" uri="sip:friendX@domain.com">
               <what>
                        <condition base-element="//tuple">rpid:type="service" or rpid:type="device"
                        </condition>
                        <include>//tuple</include>
                        <include level="ancestor">//tuple</include>
                        <include level="descendant">//tuple</include>
                        <exclude type="namespace">urn:ietf:params:xml:ns:pidf:cipid</exclude>
                </what>
            </filter>
      </filter-set>



Khartabil, et al.        Expires April 23, 2004                [Page 14]

Internet-Draft       XML Based Format for Filtering         October 2003


7. XML Schema for Filter Criteria

   XML Schema Implementation (Normative)

   <?xml version="1.0" encoding="UTF-8"?>

   <xsd:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
        xmlns="urn:ietf:params:xml:ns:simple-filter"
        xmlns:xsd=http://www.w3.org/2001/XMLSchema/>
        <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
        schemaLocation="http://www.w3.org/2001/xml.xsd">   <!--lang -->

        <xsd:annotation>
          <xsd:documentation xml:lang="en">
            XML Schema Definition for Filter Criteria.
          </xsd:documentation>
        </xsd:annotation>

        <xsd:element name="filter-set" type="FilterSetType"/>

        <xsd:complexType name="FilterSetType">
          <xsd:sequence>
            <xsd:element name="filter" type="FilterType"
                         minOccurs="1"    maxOccurs="unbounded"/>
          </xsd:sequence>
          <xsd:attribute name="package" type="xsd:string" use="optional"/>
        </xsd:complexType>

   <!--  A filter corresponds to the URI indicated by its "uri" attribute. The URI defines the user or a list of users. -->

        <xsd:complexType name="FilterType">
           <xsd:sequence>
               <xsd:element name="what" type="WhatType" minOccurs="0" maxOccurs="1"/>
               <xsd:element name="trigger" type="TriggerType" minOccurs="0" maxOccurs="unbounded"/>
           </xsd:sequence>
           <xsd:attribute name="id"  type="xsd:string" use="required"/>
           <xsd:attribute name="uri" type="xsd:anyURI" use="optional/>
           <xsd:attribute name="remove" type="xsd:boolean" default="false" use="optional"/>
        </xsd:complexType>

      <xsd:complexType name="WhatType">
         <xsd:sequence>
             <xsd:element name="condition" type="CondType" minOccurs="0" maxOccurs="unbounded"/>
             <xsd:element name="include" type="InclType" minOccurs="1" maxOccurs="unbounded"/>
             <xsd:element name="exclude" type="ExclType" minOccurs="0" maxOccurs="unbounded"/>
           <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
         </xsd:sequence>
      </xsd:complexType>



Khartabil, et al.        Expires April 23, 2004                [Page 15]

Internet-Draft       XML Based Format for Filtering         October 2003


      <xsd:complexType name="CondType">
        <xsd:simpleContent>
          <xsd:extension base="xsd:string">
               <xsd:attribute name="base-element" type="xsd:string" use="required"/>
               <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
          </xsd:extension>
         </xsd:simpleContent>
      </xsd:complexType>

      <xsd:complexType name="InclType">
         <xsd:simpleContent>
          <xsd:extension base="xsd:string">
                <xsd:attribute name="level" type="LevelType" default="self" use="optional"/>
                <xsd:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
               <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
          </xsd:extension>
         </xsd:simpleContent>
      </xsd:complexType>

      <xsd:complexType name="ExclType">
         <xsd:simpleContent>
          <xsd:extension base="xsd:string">
                <xsd:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
               <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
          </xsd:extension>
         </xsd:simpleContent>
      </xsd:complexType>

      <!--xsd:simpleType name="Base-elemType">
         <xsd:restriction base="xs:string">
                <xsd:enumeration value="current">
                <xsd:enumeration value="tuple">
                <xsd:enumeration value="watcher">
         </xsd:restriction>
      </xsd:complexType -->

      <xsd:simpleType name="LevelType">
         <xsd:restriction base="xs:string">
                <xsd:enumeration value="self">
                <xsd:enumeration value="ancestor">
                <xsd:enumeration value="descendant">
         </xsd:restriction>
      </xsd:complexType>

      <xsd:simpleType name="TypeType">
         <xsd:restriction base="xs:string">
                <xsd:enumeration value="xml-element">
                <xsd:enumeration value="namespace">



Khartabil, et al.        Expires April 23, 2004                [Page 16]

Internet-Draft       XML Based Format for Filtering         October 2003


                <xsd:enumeration value="token">
         </xsd:restriction>
      </xsd:complexType>


        <xsd:complexType name="TriggerType">
           <xsd:sequence>
               <xsd:element name="changed" type="ChangedType" minOccurs="0" maxOccurs="unbounded"/>
               <xsd:element name="added" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
               <xsd:element name="removed" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
                <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xsd:sequence>
        </xsd:complexType>

         <xs:complexType name="ChangedType">
            <xs:simpleContent>
                <xs:extension base="xds:string">
                   <xs:attribute name="changed-from" type="xsd:anySimpleType" use="optional"/>
                   <xs:attribute name="changed-to" type="xsd:anySimpleType" use="optional"/>
                   <xs:attribute name="changed-by" type="xsd:decimal" use="optional"/>
                   <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
                </xs:extension>
            </xs:simpleContent>
         </xs:complexType>

   </xsd:schema>


8. Security Requirements

   The filters in the body in a SIP message has a significant effect on
   the ways in which the request is handled at a server. As a result, it
   is especially important that messages containing this extension be
   authenticated and authorised.

   Processing of requests and looking up filter criteria requires a set
   of operations and searches, which can require some amount of
   computation. This enables a DoS attack whereby a user can send
   requests with substantial number of messages with large contents, in
   the hopes of overloading the server. To counter this, the server
   SHOULD only allow filters with no more than about 20 occurances of
   the <what>, <changed>, <added> and <removed> elements.

   Requests can reveal sensitive information about a UA's capabilities.
   If this information is sensitive, it SHOULD be encrypted using SIP S/
   MIME capabilities.

   All filtering related security measures discussed in [6] MUST be



Khartabil, et al.        Expires April 23, 2004                [Page 17]

Internet-Draft       XML Based Format for Filtering         October 2003


   followed along with package specific security.

9. Acknowledgements

   The authors would like to thank Jonathan Rosenberg, Henning
   Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla and all
   the active SIMPLE mailing list contributors for their valuable input.

10. Changes from version 00

   o  Usage of exact XPATH support restricted (XPATH compatible syntax
      still used).

   o  New solution for the content filter. Examples and XML Schema
      updated accordingly.

   o  ABNF based syntax for data referencing and expressions added.

   o  More examples added.

   o  Terminology harmonized and references updated.

   o  Minor updates concerning the triggering part.

References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Sugano, H., "CPIM Presence Information Data Format",
         draft-ietf-impp-cpim-pidf-08.txt (work in progress), May 2003.

   [3]   Schulzrinne, H., "RPID -- Rich Presence Information Data
         Format",  draft-ietf-simple-rpid-00.txt (work in progress),
         July 2003.

   [4]   Schulzrinne, H., "CIPID: Contact Information in Presence
         Information Data Format",  draft-ietf-simple-cipid-00.txt (work
         in progress), August 2003.

   [5]   Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
         for Presence",  draft-ietf-simple-presence-10.txt, January
         2003.

   [6]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [7]   Roach, A., "A Session Initiation Protocol (SIP) Event



Khartabil, et al.        Expires April 23, 2004                [Page 18]

Internet-Draft       XML Based Format for Filtering         October 2003


         Notification Extension for Resource Lists",
         draft-ietf-simple-event-list-04.txt, June 2003.

   [8]   Rosenberg, J., "An Extensible Markup Language (XML) Based
         Format for Watcher Information",
         draft-ietf-simple-winfo-format-04.txt, January 2003.

   [9]   Khartabil, H., "Requirements for Presence Specific Event
         Notification Filtering",
         draft-ietf-simple-pres-filter-reqs-02.txt (work in progress),
         August 2003.

   [10]  Kiss, K., "Requirements for Filtering of Watcher Information",
         draft-ietf-simple-winfo-filter-reqs-00.txt (work in progress),
         April 2003.

   [11]  Khartabil, H., "Functional Description of Event Notification
         Filtering",  draft-khartabil-simple-filter-funct-00.txt (work
         in progress), May 2003.

   [12]  Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-04.txt, June 2002.

   [13]  Moats, R., "The URN Syntax", RFC 2141, May 1997.

   [14]  Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [15]  Murata, M., "XML Media Types", RFC 3023, March 1997.

   [16]  Bray, T., "Exensible Markup Language (XML) 1.0 (Second
         Edition)",  W3C CR CR-xml11-20011006, October 2000.

   [17]  Clark, J., "XML Path Language (XPath) Version 1.0",  W3C REC
         REC-xpath-19991116, November 1999.

   [18]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
         RFC 2234, November 1997.













Khartabil, et al.        Expires April 23, 2004                [Page 19]

Internet-Draft       XML Based Format for Filtering         October 2003


Authors' Addresses

   Hisham Khartabil
   Nokia
   P.O. Box 321
   Helsinki
   Finland

   Phone: +358 7180 76161
   EMail: hisham.khartabil@nokia.com


   Mikko Lonnfors
   Nokia
   Itamerenkatu 00180
   Helsinki
   Finland

   Phone: + 358 50 4836402
   EMail: mikko.lonnfors@nokia.com


   Jose Costa-Requena
   Nokia
   P.O. Box 321
   FIN-00045 NOKIA GROUP
   FINLAND

   Phone: +358 71800 8000
   EMail: jose.costa-requena@nokia.com


   Eva Leppanen
   Nokia
   P.O BOX 785
   Tampere
   Finland

   Phone: +358 7180 77066
   EMail: eva-maria.leppanen@nokia.com











Khartabil, et al.        Expires April 23, 2004                [Page 20]

Internet-Draft       XML Based Format for Filtering         October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Khartabil, et al.        Expires April 23, 2004                [Page 21]

Internet-Draft       XML Based Format for Filtering         October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Khartabil, et al.        Expires April 23, 2004                [Page 22]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/