SIMPLE H. Khartabil
Internet-Draft E. Leppanen
Expires: December 23, 2004 M. Lonnfors
J. Costa-Requena
Nokia
June 24, 2004
An Extensible Markup Language (XML) Based Format for Event
Notification Filtering
draft-ietf-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 December 23, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). 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
Khartabil, et al. Expires December 23, 2004 [Page 1]
Internet-Draft XML Based Format for Filtering June 2004
to contain. This document presents a solution in the form of an XML
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 <include> Element . . . . . . . . . . . . . . . . 5
3.3.1.1 The "type" Attribute . . . . . . . . . . . . . . . 6
3.3.2 The <exclude> Element . . . . . . . . . . . . . . . . 6
3.4 The <trigger> Element . . . . . . . . . . . . . . . . . . 7
3.4.1 The <changed> Element . . . . . . . . . . . . . . . . 7
3.4.1.1 The "changed-from" Attribute . . . . . . . . . . . 7
3.4.1.2 The "changed-to" Attribute . . . . . . . . . . . . 8
3.4.1.3 The "changed-by" Attribute . . . . . . . . . . . . 8
3.4.1.4 Combination of Attributes . . . . . . . . . . . . 8
3.4.2 The <added> Element . . . . . . . . . . . . . . . . . 8
3.4.3 The <removed> Element . . . . . . . . . . . . . . . . 8
4. Syntax for Referencing XML Items and Making Logical
Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Filter Criteria Using <what> Element . . . . . . . . . . . 9
5.2 Filter Criteria Using <trigger> Element . . . . . . . . . 10
5.3 Filter Criteria Using <what> and <trigger> Elements . . . 11
5.4 Content Filter Using Namespaces . . . . . . . . . . . . . 11
5.5 Content Filter Using Only <Include> Elements . . . . . . . 12
5.6 Two Content Filters as Filter Criteria . . . . . . . . . . 12
6. XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1 application/simple-filter+xml mime TYPE . . . . . . . . . 16
8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
10.2 Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Khartabil, et al. Expires December 23, 2004 [Page 2]
Internet-Draft XML Based Format for Filtering June 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 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 [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 Filter Criteria
The filter criteria is an XML document [8] 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 December 23, 2004 [Page 3]
Internet-Draft XML Based Format for Filtering June 2004
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 [5], using the namespace identifier 'ietf' defined by [6]
and extended by [4]. 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 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 URI attribute MAY also carry a domain. In this case, the filter
Khartabil, et al. Expires December 23, 2004 [Page 4]
Internet-Draft XML Based Format for Filtering June 2004
applies to resources in that domain. This can be used when a
subscription is for a resource that is an event list with many
resources from differing domains.
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> 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 one or more <include> elements and one
or more <exclude> elements. However, the <what> element MUST contain
at least one <include> element. When more than one <include> element
has been defined, the result is the union of all the <include>
elements. When more than one <exclude> element has been defined, the
result is the union of all the <exclude> elements.
3.3.1 The <include> Element
The <include> element is used to select the content to be delivered.
Its value can identify XML elements, an attribute or a namespace of
XML document to be filtered. This is indicated using the "type"
attribute. The <include> element, if identifying elements, MUST
identify one element only, unless the conditional expression results
in more than one element with the same name being identified.
Note that the resulting XML document MUST be valid. Therefore, in
addition to including the elements identified with the <include>
element, 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.
The following example selects the <status> element defined in the
PIDF XML document [11]. This results in the selection of all the
ancestors of <status>. I.e. <basic> and <tuple>.
<include type="xml-element">//tuple/status</include>.
Khartabil, et al. Expires December 23, 2004 [Page 5]
When identifying XML elements, the value may consist of two parts
(similar to XPath [9]): the XML element selector and the condition
(comparison and logical expressions). The syntax is defined in
section Section 4 (see the definition of "selection".)
3.3.1.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' and
'namespace'. The "type" attribute is optional, and, if omitted, the
default value is 'xml-element'.
The syntax is defined in a way that follows XPath. 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 Selection by using an XML element as a condition:
* //*[status/basic="open"]
* /presence/tuple[*/basic="open"]
o Selection by using XML attributes as a condition :
* //watcher[@duration-subscribed<500]
* /*/watcher[@event="rejected"]
o Selection by using two XML elements as a condition :
* //tuple[status/basic="open" and type="device"]
The "namespace" value is used when the <include> 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.3.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)
Khartabil, et al. Expires December 23, 2004 [Page 6]
Internet-Draft XML Based Format for Filtering June 2004
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.3.1.1).
The <exclude> element MUST NOT be used if there are no <include>
element(s) 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
attribute is identified using the syntax defined in Section 4 for the
"reference". The <changed> element MUST identify only 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.
Khartabil, et al. Expires December 23, 2004 [Page 7]
Internet-Draft XML Based Format for Filtering June 2004
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".
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".
Khartabil, et al. Expires December 23, 2004 [Page 8]
Internet-Draft XML Based Format for Filtering June 2004
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.
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>
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.
Khartabil, et al. Expires December 23, 2004 [Page 9]
Internet-Draft XML Based Format for Filtering June 2004
This example shows how to define a content filter. The <basic>
element as well as all parent elements of the tuples of the presence
information 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].
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">
<simple-filter:filter id="123" uri="sip:presentity@domain.com">
<simple-filter:what>
<simple-filter:include type="xml-element">
//pidf:tuple/pidf:status/pidf:basic[rpid:class="IM"
or rpid:class="SMS" or rpid:class="MMS"]
</simple-filter:include>
</simple-filter:what>
</simple-filter: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 colleaque.
The filter selects the content to be delivered to the subscriber when
a certain PIDF [11] 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"">
<simple-filter:filter id="123" uri="sip:presentity@domain.com">
<simple-filter:trigger>
<simple-filter:changed changed-from="CLOSED" changed-to="OPEN">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic
</simple-filter:changed>
</simple-filter:trigger>
</simple-filter:filter>
</filter-set>
Khartabil, et al. Expires December 23, 2004 [Page 10]
Internet-Draft XML Based Format for Filtering June 2004
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
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">
<simple-filter:filter id="123" uri="sip:presentity@domain.com">
<simple-filter:what>
<simple-filter:include>
wi:watcher[@wi:status="pending" or @wi:status="waiting"]
</simple-filter:include>
</simple-filter:what>
<simple-filter:trigger>
<simple-filter:changed changed-to="pending">
//wi:watcher/@wi:status@status
</simple-filter:changed>
<simple-filter:changed changed-to="waiting">
//wi:watcher/@wi:status@status
</simple-filter:changed>
</simple-filter:trigger>
</simple-filter: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">
<simple-filter:filter id="123" uri="sip:buddylist@domain.com">
<simple-filter:what>
<simple-filter:include type="namespace">
urn:ietf:params:xml:ns:pidf
</simple-filter:include>
</simple-filter:what>
Khartabil, et al. Expires December 23, 2004 [Page 11]
Internet-Draft XML Based Format for Filtering June 2004
</simple-filter:filter>
</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" >
<simple-filter:filter id="123">
<simple-filter:what>
<simple-filter:include>
//pidf:tuple/pidf:status[game-ext:label="game-X"]
</simple-filter:include>
</simple-filter:what>
</simple-filter: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 December 23, 2004 [Page 12]
Internet-Draft XML Based Format for Filtering June 2004
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<simple-filter:filter id="8439" uri="sip:buddies@domain.com">
<simple-filter:what>
<simple-filter:include>
//pidf:tuple/pidf:status/pidf:basic[rpid:type="service"]
</simple-filter:include>
</simple-filter:what>
</simple-filter:filter>
<simple-filter:filter id="999" uri="sip:bob@domain.com">
<simple-filter:what>
<simple-filter:include type="namespace">
urn:ietf:params:xml:ns:pidf
</simple-filter:include>
<simple-filter:exclude>
//pidf:tuple/pidf:note
</simple-filter:exclude>
</simple-filter:what>
</simple-filter: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">
<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">
<xs:sequence>
<xs:element name="filter" type="FilterType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="package" type="xs:string" use="optional"/>
</xs:complexType>
Khartabil, et al. Expires December 23, 2004 [Page 13]
Internet-Draft XML Based Format for Filtering June 2004
<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: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:anyURI" use="optional"/>
<xs:attribute name="remove" type="xs:boolean" default="false"
use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="WhatType">
<xs:sequence>
<xs:element name="include" type="InclType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="exclude" type="ExclType"
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="xml-element" 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="xml-element" 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="xml-element"/>
<xs:enumeration value="namespace"/>
Khartabil, et al. Expires December 23, 2004 [Page 14]
Internet-Draft XML Based Format for Filtering June 2004
<xs:enumeration value="token"/>
</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="changed-from" type="xs:anySimpleType"
use="optional"/>
<xs:attribute name="changed-to" type="xs:anySimpleType"
use="optional"/>
<xs:attribute name="changed-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
SHOULD only allow filters with no more than about 20 occurrences of
the <what>, <changed>, <added> and <removed> elements.
Khartabil, et al. Expires December 23, 2004 [Page 15]
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
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 8 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)
Khartabil, et al. Expires December 23, 2004 [Page 16]
Internet-Draft XML Based Format for Filtering June 2004
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:
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 and all
the active SIMPLE mailing list contributors for their valuable input.
10. References
10.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Khartabil, et al. Expires December 23, 2004 [Page 17]
Internet-Draft XML Based Format for Filtering June 2004
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",
draft-mealling-iana-xmlns-registry-04.txt, June 2002.
[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.
[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", draft-ietf-simple-presence-10.txt, January
2003.
[14] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information",
draft-ietf-simple-winfo-format-04.txt, January 2003.
[15] Roach, A., "A Session Initiation Protocol (SIP) Event
Notification Extension for Resource Lists",
draft-ietf-simple-event-list-04.txt, June 2003.
Khartabil, et al. Expires December 23, 2004 [Page 18]
Internet-Draft XML Based Format for Filtering June 2004
Authors' Addresses
Hisham Khartabil
Nokia
P.O. Box 321
Helsinki
Finland
Phone: +358 7180 76161
EMail: hisham.khartabil@nokia.com
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 December 23, 2004 [Page 19]
Internet-Draft XML Based Format for Filtering June 2004
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 (2004). 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 December 23, 2004 [Page 20]
Internet-Draft XML Based Format for Filtering June 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Khartabil, et al. Expires December 23, 2004 [Page 21]
