SIMPLE                                                      H. Khartabil
Internet-Draft                                               E. Leppanen
Expires: February 9, 2005                                    M. Lonnfors
                                                        J. Costa-Requena
                                                                   Nokia
                                                         August 11, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 February 9, 2005.

Copyright Notice

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

Abstract

   Filtering is a mechanism for defining the preferred content to be
   delivered and for specifying the rules for when the content should be
   delivered.  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 document format.



Khartabil, et al.       Expires February 9, 2005                [Page 1]


   The filtering mechanism is expected to be particularly valuable and
   primarily applicable to users of mobile wireless access devices.


Table of Contents

   1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Structure of XML-Encoded SIMPLE Filter . . . . . . . . . . . .  3
     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 . . . . . . . . . . . . . . . . . . . .  5
       3.5.1   The <include> Element  . . . . . . . . . . . . . . . .  6
       3.5.2   The <exclude> Element  . . . . . . . . . . . . . . . .  6
       3.5.3   The 'type' Attribute . . . . . . . . . . . . . . . . .  7
     3.6   The <trigger> Element  . . . . . . . . . . . . . . . . . .  7
       3.6.1   The <changed> Element  . . . . . . . . . . . . . . . .  7
         3.6.1.1   The 'from' Attribute . . . . . . . . . . . . . . .  8
         3.6.1.2   The 'to' Attribute . . . . . . . . . . . . . . . .  8
         3.6.1.3   The 'by' Attribute . . . . . . . . . . . . . . . .  8
         3.6.1.4   Combination of Attributes  . . . . . . . . . . . .  8
       3.6.2   The <added> Element  . . . . . . . . . . . . . . . . .  9
       3.6.3   The <removed> Element  . . . . . . . . . . . . . . . .  9
   4.  Syntax for Referencing XML Items and Making Logical
       Expressions  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1   Filter Criteria Using <what> Element . . . . . . . . . . . 11
     5.2   Filter Criteria Using <trigger> Element  . . . . . . . . . 12
     5.3   Filter Criteria Using <what> and <trigger> Elements  . . . 12
     5.4   Content Filter Using Namespaces  . . . . . . . . . . . . . 13
     5.5   Content Filter Using Only <include> Elements . . . . . . . 14
     5.6   Two Content Filters as Filter Criteria . . . . . . . . . . 14
   6.  XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
     8.1   application/simple-filter+xml MIME TYPE  . . . . . . . . . 18
     8.2   URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 19
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 20
   10.2  Informative References . . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 23







Khartabil, et al.       Expires February 9, 2005                [Page 2]

Internet-Draft       XML Based Format for Filtering          August 2004


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.

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

   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 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 [13] the change in the value of the
   <status> element.

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

3.  Structure of XML-Encoded SIMPLE Filter

   The simple-filter is an XML document [8] that MUST be well-formed and
   SHOULD be valid.  The simple-filter documents MUST be based on XML



Khartabil, et al.       Expires February 9, 2005                [Page 3]

Internet-Draft       XML Based Format for Filtering          August 2004


   1.0 and MUST be encoded using UTF-8.

   The namespace identifier for elements defined by this specification
   is a URN [5], using 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 on.

3.1  MIME Type for simple-filter Document

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

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 The <filter-set> element may contain one <ns-bindings> elements.

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






Khartabil, et al.       Expires February 9, 2005                [Page 4]

Internet-Draft       XML Based Format for Filtering          August 2004


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 an 'uri' attribute.  The value of the 'uri'
   attribute is the URI of the resource which the filter applies to.
   The <filter> MAY have an 'domain' attribute.  The value of the
   'domain' attribute is the domain of the resources that the filter
   applies to.  The 'uri' attribute and the 'domain' attribute MUST NOT
   appear together in a filter.

   The URI of the resource is useful in cases where the 'event list'
   extension [15] 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 who's 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 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 is "false".

   The <filter> MAY have a 'enabled' attribute which 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 MUST contain either the <what>
   element or the <trigger> element.

3.5  The <what> Element

   The <what> element is used to specify the content to be delivered to



Khartabil, et al.       Expires February 9, 2005                [Page 5]

Internet-Draft       XML Based Format for Filtering          August 2004


   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.  I.e.  each <include> element
   contents adds an element or attribute to the resulting XML document.
   When more than one <exclude> element has been defined, each value it
   each <exclude> element 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
   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 4 (see the definition of "selection".)
   MUST be used.  The following example selects the <status> element
   defined in the PIDF [11].  This results in the selection of the
   <status> element as well as all the ancestors of <status>.  I.e.
   <basic> and <tuple>.

   <include type="xpath">//tuple/status</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,
   those 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).




Khartabil, et al.       Expires February 9, 2005                [Page 6]

Internet-Draft       XML Based Format for Filtering          August 2004


   Note that the resulting XML document MUST be valid.  Therefore, if
   applying the <exclude> element value to an XML document results in an
   invalid document according to the schema, the mandatory elements and/
   or attributes must be re-introduced into the resulting XML document
   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 4.

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 4 that selects and
   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 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.6.1  The <changed> Element

   The <changed> element is used to identify the XML element or



Khartabil, et al.       Expires February 9, 2005                [Page 7]

Internet-Draft       XML Based Format for Filtering          August 2004


   attribute, from the package specific XML document, who's value MUST
   change, compared to 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 last XML document that was
   selected for delivery to that specific subscriber before the filter
   was applied to it.  The XML element or attribute MUST be expressed
   using the syntax defined in Section 4 for the "reference" ABNF.

   The <changed> element MAY contain the 'from' attribute, 'to'
   attribute, 'by' attribute, or any combination of the three.  The
   absence of all 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 with a case sensitive string
   comparson.  This applies to elements or attributes that don't carry a
   numerical value.  Numerical values are considered changed when the
   value has incread or decreased.

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 the value indicated by this
   attribute from a different value.  I.e.  The 'by' attribute applies
   only to numerical values and indicates a delta with respect 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 lower
   value.

3.6.1.4  Combination of Attributes

   Any combination of the 'from', 'to', and 'by' attributes in the



Khartabil, et al.       Expires February 9, 2005                [Page 8]

Internet-Draft       XML Based Format for Filtering          August 2004


   <changed> element is possible.  For example, if the 'from' attribute
   was combined with the '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 '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 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 MUST be expressed using the syntax defined in Section 4 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 cover also the added elements, or otherwise the content is
   delivered without the items defined in the <added> element.

3.6.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 MUST be expressed using the syntax
   defined in Section 4 for the "reference" ABNF.

4.  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
   step, the filter applies to all the elements that are evaluated.
   I.e.  If a filter including a element evaluates to 2 elements, both
   elements are included as a result.






Khartabil, et al.       Expires February 9, 2005                [Page 9]

Internet-Draft       XML Based Format for Filtering          August 2004


   selection = reference [expression]
   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 = elem-reference / attr-reference
   elem-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>

   When identifying XML elements or attributes, the value may consist of
   two parts: the XML element/attribute selector and the condition
   (comparison and logical expressions).  The XML element selector
   appears first followed by the condition part in square brackets.  In
   the XML element selector part the XML elements may be referenced by
   giving the full hierarchical path as: "/presence/tuple/status/basic",
   or by denoting the selection to cover any hierarchical level by its
   name as: "//basic" or using the wildcard "*" denoting any value in a
   certain level as "/*/watcher".

   Example references are listed as follows:


   o  Selecting an element by using an XML element as a condition:

      *  //*[status/basic="open"]

      *  /presence/tuple[*/basic="open"]

   o  Selecting an element by using XML attributes as a condition :

      *  //watcher[@duration-subscribed<500]

      *  /*/watcher[@event="rejected"]

   o  Selecting an element by using two XML elements as a condition :




Khartabil, et al.       Expires February 9, 2005               [Page 10]

Internet-Draft       XML Based Format for Filtering          August 2004


      *  //tuple[status/basic="open" and type="device"]

   o  Selecting an attribute :

      *  //watcher/@duration-subscribed


   According to the ABNF above, the XPATH-like expression cannot and
   MUST NOT identify more than one element or attribute.  However, in
   some cases due to the design of the XML schema, the expression
   results in identifying more than one element with the same name (the
   XPATH expression does not uniquely identify an element at every
   step).  In other cases, it is possible that more than one element or
   attribute is identified due to the condition part resulting in the
   the selection of more than one element or attribute with the same
   name.  In those cases, all elements identified are selected.

5.  Examples

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

5.1  Filter Criteria Using <what> Element

   A user wishes to get to know his friend's availability and
   willingness for messaging (SMS, IM and MMS) in order to know whether
   the friend is able to receive a message, the address to contact and
   the type of the message to be used.

   This example shows how to define a content filter.  The <basic>
   element as well as all parent elements are selected based on a
   condition defined by a logical expression.  The condition is: <class>
   elements that have a value "MMS", "SMS" or "IM".

   The <class> element is defined in [12] as an extension to PIDF [11].
















Khartabil, et al.       Expires February 9, 2005               [Page 11]

Internet-Draft       XML Based Format for Filtering          August 2004


   <?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-binding prefix="rpid"
                          urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
     </ns-bindings>
     <filter id="123" uri="sip:presentity@domain.com">
       <what>
         <include type="xpath">
           //pidf:tuple[rpid:class="IM" or rpid:class="SMS"
           or rpid:class="MMS"]/pidf:status/pidf:basic
         </include>
       </what>
     </filter>
   </filter-set>


5.2  Filter Criteria Using <trigger> Element

   A user requires to get informed when his colleague becomes available
   by some communication mean(s).  The user gets the full presence state
   of the colleague when a certain PIDF [11] tuple <basic> status
   changes from 'CLOSED' to 'OPEN'.

   <?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="123" uri="sip:presentity@domain.com">
       <trigger>
         <changed from="CLOSED" to="OPEN">
           /pidf:presence/pidf:tuple/pidf:status/pidf:basic
         	</changed>
   </trigger>
   </filter>
   </filter-set>


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

   A user wishes to get information about pending and waiting
   subscriptions in order to be able to authorise watchers to see his
   presence information.

   The filter selects watcher information notifications [14] to be sent
   when a subscription status has changed to "pending" or "waiting".  In



Khartabil, et al.       Expires February 9, 2005               [Page 12]

Internet-Draft       XML Based Format for Filtering          August 2004


   the notification, only the watchers that have a status of "pending"
   or "waiting" are included.

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
     <ns-bindings>
       <ns-binding prefix="wi"
                          urn="urn:ietf:params:xml:ns:watcherinfo"/>
     </ns-bindings>
     <filter id="123" uri="sip:presentity@domain.com">
       <what>
         <include>
           //wi:watcher[@status="pending" or @status="waiting"]
         </include>
       </what>
       <trigger>
         <changed to="pending">
           //wi:watcher/@status
         </changed>
       </trigger>
       <trigger>
         <changed to="waiting">
           //wi:watcher/@status
         </changed>
       </trigger>
     </filter>
   </filter-set>


5.4  Content Filter Using Namespaces

   A user turns her terminal on and the terminal automatically fetches
   general presence status and information about communication means
   from a certain pre-defined set of her buddies.

   The filter is defined to select XML elements belonging to the pidf
   namespace.

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



Khartabil, et al.       Expires February 9, 2005               [Page 13]

Internet-Draft       XML Based Format for Filtering          August 2004


5.5  Content Filter Using Only <include> Elements

   A user wants to know if a group of his friends are available for
   gaming.  He orders notifications about the current status and future
   changes of the game specific presence information.

   This filter is defined to select the game specific tuple to be
   delivered.

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" >
     <ns-bindings>
       <ns-binding prefix="game-ext"
                          urn="urn:ietf:params:xml:ns:game-ext"/>
     </ns-bindings>
     <filter id="123">
       <what>
         <include>
           //pidf:tuple/pidf:status[game-ext:label="game-X"]
         </include>
       </what>
     </filter>
   </filter-set>


5.6  Two Content Filters as Filter Criteria

   The user is interested in getting up-to-date information about the
   communication means and contact addresses of his friends.  The user
   wants to get also more information (e.g.  location) about one of the
   friends in the list named Bob.  The PIDF element <note> is filtered
   out, i.e.  excluded.  The list was predefined as buddies@domain.com.



















Khartabil, et al.       Expires February 9, 2005               [Page 14]

Internet-Draft       XML Based Format for Filtering          August 2004


   <?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-binding prefix="rpid"
                          urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
     </ns-bindings>
     <filter id="8439" uri="sip:buddies@domain.com">
       <what>
         <include>
           //pidf:tuple[rpid:class="service"]/pidf:status/pidf:basic
         </include>
       </what>
       </filter>
     <filter id="999" uri="sip:bob@domain.com">
       <what>
         <include type="namespace">
           urn:ietf:params:xml:ns:pidf
         </include>
         <exclude>
           //pidf:tuple/pidf:note
         </exclude>
       </what>
     </filter>
   </filter-set>

6.  XML Schema for Filter Criteria

   XML Schema Implementation (Normative)

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
   	xmlns="urn:ietf:params:xml:ns:simple-filter"
   	xmlns:xs="http://www.w3.org/2001/XMLSchema"
   	elementFormDefault="qualified">

     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                      schemaLocation="http://www.w3.org/2001/xml.xsd"/>

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

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

     <xs:complexType name="FilterSetType">



Khartabil, et al.       Expires February 9, 2005               [Page 15]

Internet-Draft       XML Based Format for Filtering          August 2004


       <xs:sequence>
         <xs:element name="ns-bindings" type="NSBindings"
                             minOccurs="0" maxOccurs="1"/>
         <xs:element name="filter" type="FilterType"
                             minOccurs="1"    maxOccurs="unbounded"/>
         </xs:sequence>
       <xs:attribute name="package" type="xs:string" use="optional"/>
     </xs:complexType>

     <xs:complexType name="NSBindings">
       <xs:sequence>
         <xs:element name="ns-binding" type="NSBinding"
                             minOccurs="1" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="NSBinding">
       <xs:attribute name="prefix" type="xs:string" use="required"/>
       <xs:attribute name="urn" type="xs:anyURI" use="required"/>
     </xs:complexType>

     <xs:complexType name="FilterType">
       <xs:sequence>
         <xs:element name="what" type="WhatType"
                             minOccurs="0" maxOccurs="1"/>
         <xs:element name="trigger" type="TriggerType"
                             minOccurs="0" maxOccurs="unbounded"/>
         <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id"  type="xs:string" use="required"/>
       <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
       <xs:attribute name="domain" type="xs:string" use="optional"/>
       <xs:attribute name="remove" type="xs:boolean" use="optional"
                            default="false"/>
       <xs:attribute name="enabled" type="xs:boolean" use="optional"
                            default="true"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>

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



Khartabil, et al.       Expires February 9, 2005               [Page 16]

Internet-Draft       XML Based Format for Filtering          August 2004


       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="InclType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType"
                                default="xpath" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

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

     <xs:simpleType name="TypeType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="xpath"/>
         <xs:enumeration value="namespace"/>
       </xs:restriction>
     </xs:simpleType>

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

     <xs:complexType name="ChangedType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="from" type="xs:anySimpleType"
                                use="optional"/>



Khartabil, et al.       Expires February 9, 2005               [Page 17]

Internet-Draft       XML Based Format for Filtering          August 2004


           <xs:attribute name="to" type="xs:anySimpleType"
                                use="optional"/>
           <xs:attribute name="by" type="xs:decimal"
                                use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

   </xs:schema>


7.  Security Considerations

   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
   MUST establish a limit on the number of occurrences of the  <what>,
   <changed>, <added> and <removed> elements allowed in the filters.  A
   default limit of 20 is RECOMMENDED, however, servers MAY raise or
   lower the limit depending upon their specific engineered capacity.

   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 [2] MUST be
   followed along with package specific security.

8.  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 [7].

8.1  application/simple-filter+xml MIME TYPE

   MIME media type: application

   MIME subtype name: simple-filter+xml



Khartabil, et al.       Expires February 9, 2005               [Page 18]

Internet-Draft       XML Based Format for Filtering          August 2004


   Mandatory parameters: none

   Optional parameters: Same as charset parameter application/xml as
   specified in RFC 3023 [7].

   Encoding considerations: Same as encoding considerations of
   application/xml as specified in RFC 3023 [7].

   Security considerations: See section 10 of RFC 3023 [7] and section
   Section 7 of this document.

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type has been
   used to support SIP based Event notification framework and its
   packages.

   Additional information:

   Magic number: None

   File extension: .cl or .xml

   Macintosh file type code: "TEXT"

   Personal and email address for further information: Hisham Khartabil
   (hisham.khartabil@nokia.com)

   Intended Usage: COMMON

   Author/change controller: The IETF

8.2  URN Sub-Namespace Registration for
    urn:ietf:params:xml:ns:simple-filter

   This section registers a new XML namespace, as per guidelines in URN
   document [4].

   URI: The URI for this namespace is
   urn:ietf:params:xml:ns:simple-filter.

   Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
   (hisham.khartabil@nokia.com)

   XML:




Khartabil, et al.       Expires February 9, 2005               [Page 19]

Internet-Draft       XML Based Format for Filtering          August 2004


   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
    <meta http-equiv="content-type"
      content="text/html;charset=iso-8859-1"/>
    <title>Event Notification Filtering Namespace</title>
   </head>
   <body>
     <h1>Namespace for Event Notification Filtering</h1>
     <h2>application/simple-filter+xml</h2>
     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
   </body>
   </html>
   END


9.  Acknowledgements

   The authors would like to thank Jonathan Rosenberg, Henning
   Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla,
   Miguel-Angel Garcia Martin, Mary Barnes and Paul Kyzivat for their
   valuable input and comments.

10.  References

10.1  Normative References

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

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

   [3]   Khartabil, H., "Functional Description of Event Notification
         Filtering",  draft-simple-filter-funct-00.txt (work in
         progress), February 2004.

   [4]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

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

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

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



Khartabil, et al.       Expires February 9, 2005               [Page 20]

Internet-Draft       XML Based Format for Filtering          August 2004


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

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

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

10.2  Informative References

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

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

   [13]  Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
         for Presence", RFC RFC3856, July 2004.

   [14]  Rosenberg, J., "An Extensible Markup Language (XML) Based
         Format for Watcher Information", RFC RFC3858, July 2004.

   [15]  Roach, A., "A Session Initiation Protocol (SIP) Event
         Notification Extension for Resource Lists",
         draft-ietf-simple-event-list-04.txt, June 2003.


Authors' Addresses

   Hisham Khartabil
   Nokia
   P.O. Box 321
   Helsinki
   Finland

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












Khartabil, et al.       Expires February 9, 2005               [Page 21]

Internet-Draft       XML Based Format for Filtering          August 2004


   Eva Leppanen
   Nokia
   P.O BOX 785
   Tampere
   Finland

   Phone: +358 7180 77066
   EMail: eva-maria.leppanen@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























Khartabil, et al.       Expires February 9, 2005               [Page 22]

Internet-Draft       XML Based Format for Filtering          August 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Khartabil, et al.       Expires February 9, 2005               [Page 23]