SIMPLE H. Khartabil
Internet-Draft Telio
Expires: July 15, 2005 E. Leppanen
M. Lonnfors
J. Costa-Requena
Nokia
January 14, 2005
An Extensible Markup Language (XML) Based Format for Event
Notification Filtering
draft-ietf-simple-filter-format-04
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 July 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
Khartabil, et al. Expires July 15, 2005 [Page 1]
Internet-Draft XML Based Format for Filtering January 2005
a mechanism of how 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 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.
The filtering mechanism is expected to be particularly valuable and
primarily applicable to users of mobile wireless access devices.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure of XML-Encoded simple-filter . . . . . . . . . . . . 5
3.1 MIME Type for simple-filter Document . . . . . . . . . . . 5
3.2 The <filter-set> Root Element . . . . . . . . . . . . . . 5
3.3 The <ns-bindings> Element . . . . . . . . . . . . . . . . 5
3.4 The <filter> Element . . . . . . . . . . . . . . . . . . . 6
3.5 The <what> Element . . . . . . . . . . . . . . . . . . . . 7
3.5.1 The <include> Element . . . . . . . . . . . . . . . . 7
3.5.2 The <exclude> Element . . . . . . . . . . . . . . . . 8
3.5.3 The 'type' Attribute . . . . . . . . . . . . . . . . . 8
3.6 The <trigger> Element . . . . . . . . . . . . . . . . . . 8
3.6.1 The <changed> Element . . . . . . . . . . . . . . . . 9
3.6.1.1 The 'from' Attribute . . . . . . . . . . . . . . . 9
3.6.1.2 The 'to' Attribute . . . . . . . . . . . . . . . . 9
3.6.1.3 The 'by' Attribute . . . . . . . . . . . . . . . . 9
3.6.1.4 Combination of Attributes . . . . . . . . . . . . 10
3.6.2 The <added> Element . . . . . . . . . . . . . . . . . 10
3.6.3 The <removed> Element . . . . . . . . . . . . . . . . 10
4. Syntax for Referencing XML Items and Making Logical
Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Filter Criteria Using <what> Element . . . . . . . . . . . 12
5.2 Filter Criteria Using <trigger> Element . . . . . . . . . 13
5.3 Filter Criteria Using <what> and <trigger> Elements . . . 13
5.4 Content Filter Using Namespaces . . . . . . . . . . . . . 14
5.5 Content Filter Using Only <include> Elements . . . . . . . 15
5.6 Two Content Filters as Filter Criteria . . . . . . . . . . 15
6. XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1 application/simple-filter+xml MIME TYPE . . . . . . . . . 19
8.2 URN Sub-Namespace Registration for
Khartabil, et al. Expires July 15, 2005 [Page 2]
Internet-Draft XML Based Format for Filtering January 2005
urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
10.2 Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24
Khartabil, et al. Expires July 15, 2005 [Page 3]
Internet-Draft XML Based Format for Filtering January 2005
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 of how 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 7.
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 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.
Khartabil, et al. Expires July 15, 2005 [Page 4]
Internet-Draft XML Based Format for Filtering January 2005
"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], 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 (SIP [12],
for example) 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 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> 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.
Khartabil, et al. Expires July 15, 2005 [Page 5]
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 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 [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 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 when the filter is being enabled for
Khartabil, et al. Expires July 15, 2005 [Page 6]
Internet-Draft XML Based Format for Filtering January 2005
the first time. When a filter is disabled by setting the 'enabled'
attribute to "false", the <what> and <trigger> elements MAY be
omitted. Similarily, 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. 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 <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
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 [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>.
Khartabil, et al. Expires July 15, 2005 [Page 7]
Internet-Draft XML Based Format for Filtering January 2005
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).
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 reveresed 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 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.
Khartabil, et al. Expires July 15, 2005 [Page 8]
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
attribute, from the package specific XML document, whose 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 any 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 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. 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
Khartabil, et al. Expires July 15, 2005 [Page 9]
Internet-Draft XML Based Format for Filtering January 2005
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
<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 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 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 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 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 the this 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
Khartabil, et al. Expires July 15, 2005 [Page 10]
Internet-Draft XML Based Format for Filtering January 2005
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.
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: "/presence/tuple/status/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 :
Khartabil, et al. Expires July 15, 2005 [Page 11]
Internet-Draft XML Based Format for Filtering January 2005
* //watcher[@duration-subscribed<500]
* /*/watcher[@event="rejected"]
o Selecting an element by using two XML elements as a condition :
* //tuple[status/basic="open" and type="device"]
o Selecting an attribute :
* //watcher/@duration-subscribed
In some cases, due to the design of the XML schema, the XPATH-like
expression results in identifying more than one element with the same
name (the XPATH expression may not have uniquely identified an
element at every step). In those cases, all elements identified are
selected.
When evaluating XPath location steps, namespace expansion follows
XPath 1.0 [9] semantics, i.e. if the QName does not have a prefix
then the namespace URI in the expanded name is null. With
non-default namespaces, expansion is done according to the given
<ns-bindings> definitions. When there's a default namespace used in
the document, <ns-binding> element SHOULD be used to define an equal
URI with some prefix in order to have a valid XPath evaluation in
location steps.
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 [14] as an extension to PIDF [13].
Khartabil, et al. Expires July 15, 2005 [Page 12]
Internet-Draft XML Based Format for Filtering January 2005
<?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:presence/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 [13] 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 [16] to be sent
when a subscription status has changed to "pending" or "waiting". In
Khartabil, et al. Expires July 15, 2005 [Page 13]
Internet-Draft XML Based Format for Filtering January 2005
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:watcherinfo/wi:watcher-list/wi:watcher[@status="pending"
or @status="waiting"]
</include>
</what>
<trigger>
<changed to="pending">
/wi:watcherinfo/wi:watcher-list/wi:watcher/@status
</changed>
</trigger>
<trigger>
<changed to="waiting">
/wi:watcherinfo/wi:watcher-list/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>
Khartabil, et al. Expires July 15, 2005 [Page 14]
Internet-Draft XML Based Format for Filtering January 2005
</filter-set>
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:presence/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 July 15, 2005 [Page 15]
Internet-Draft XML Based Format for Filtering January 2005
<?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:presence/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:presence/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"/>
Khartabil, et al. Expires July 15, 2005 [Page 16]
Internet-Draft XML Based Format for Filtering January 2005
<xs:complexType name="FilterSetType">
<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"
Khartabil, et al. Expires July 15, 2005 [Page 17]
Internet-Draft XML Based Format for Filtering January 2005
minOccurs="0" maxOccurs="unbounded"/>
</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"
Khartabil, et al. Expires July 15, 2005 [Page 18]
Internet-Draft XML Based Format for Filtering January 2005
use="optional"/>
<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.
Requests can reveal sensitive information about a UA's capabilities.
If this information is sensitive, it SHOULD be encrypted using SIP
S/MIME capabilities [11].
All filtering related security measures discussed in [2] MUST be
followed along with package specific security.
It is important to note that a flitered document located at a
subscriber may project false reality. For example, if a subscriber
asked to be notified when a resource has changed his presence state
from closed to open but not from open to closed, then the subscriber
may afterwards be under the false impression that the resource's
presence state is open even long after the resource has changed it to
closed. Therefore, subscribers need to be sure what they put in a
filter, understand what they asked for and be prepared to be out of
sync with the real state of a resource.
8. IANA Considerations
This document registers a new MIME type
"application/simple-filter+xml", and registers a new XML namespace.
This specification follows the guidelines of RFC3023 [7].
8.1 application/simple-filter+xml MIME TYPE
MIME media type: application
Khartabil, et al. Expires July 15, 2005 [Page 19]
Internet-Draft XML Based Format for Filtering January 2005
MIME subtype name: simple-filter+xml
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)
Khartabil, et al. Expires July 15, 2005 [Page 20]
Internet-Draft XML Based Format for Filtering January 2005
XML:
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, Paul Kyzivat, Robert Sparks
and Elwyn Davies 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-event-filter-funct-04.txt, January
2005.
[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.
Khartabil, et al. Expires July 15, 2005 [Page 21]
Internet-Draft XML Based Format for Filtering January 2005
[7] Murata, M., "XML Media Types", RFC 3023, March 1997.
[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.
[11] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
10.2 Informative References
[12] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[13] Sugano, H., "Presence Information Data Format", RFC 3863,
Auguest 2004.
[14] Schulzrinne, H., "RPID -- Rich Presence Information Data
Format", draft-ietf-simple-rpid-00.txt (work in progress), May
2004.
[15] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
for Presence", RFC 3856, July 2004.
[16] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, July 2004.
[17] 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
Telio
P.O. Box 1203 Vika
Oslo
Norway
Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no
Khartabil, et al. Expires July 15, 2005 [Page 22]
Internet-Draft XML Based Format for Filtering January 2005
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 July 15, 2005 [Page 23]
Internet-Draft XML Based Format for Filtering January 2005
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 (2005). 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 July 15, 2005 [Page 24]
