< draft-ietf-simple-filter-format-04.txt   draft-ietf-simple-filter-format-05.txt >
SIMPLE H. Khartabil SIMPLE H. Khartabil
Internet-Draft Telio Internet-Draft Telio
Expires: July 15, 2005 E. Leppanen Expires: September 16, 2005 E. Leppanen
M. Lonnfors M. Lonnfors
J. Costa-Requena J. Costa-Requena
Nokia Nokia
January 14, 2005 March 15, 2005
An Extensible Markup Language (XML) Based Format for Event An Extensible Markup Language (XML) Based Format for Event
Notification Filtering Notification Filtering
draft-ietf-simple-filter-format-04 draft-ietf-simple-filter-format-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2005. This Internet-Draft will expire on September 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The SIP event notification framework describes the usage of the The SIP event notification framework describes the usage of the
Session Initiation Protocol (SIP) for subscriptions and notifications Session Initiation Protocol (SIP) for subscriptions and notifications
of changes to a state of a resource. The document does not describe of changes to a state of a resource. The document does not describe
a mechanism of how filtering of event notification information can be a mechanism of how filtering of event notification information can be
achieved. Filtering is a mechanism for defining the preferred achieved. Filtering is a mechanism for defining the preferred
notification information to be delivered and for specifying triggers notification information to be delivered and for specifying triggers
that cause that information to be delivered. In order to enable that cause that information to be delivered. In order to enable
this, a format is needed to enable the subscriber to choose when this, a format is needed to enable the subscriber to describe the
notifications are to be sent to it and what they are to contain. state changes of a resource that cause notifications to be sent to it
This document presents a solution in the form of an XML document and what those notifications are to contain. This document presents
format. a format in the form of an XML document.
The filtering mechanism is expected to be particularly valuable and
primarily applicable to users of mobile wireless access devices.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure of XML-Encoded simple-filter . . . . . . . . . . . . 5 3. Structure of XML-Encoded simple-filter . . . . . . . . . . . . 5
3.1 MIME Type for simple-filter Document . . . . . . . . . . . 5 3.1 MIME Type for simple-filter Document . . . . . . . . . . . 5
3.2 The <filter-set> Root Element . . . . . . . . . . . . . . 5 3.2 The <filter-set> Root Element . . . . . . . . . . . . . . 5
3.3 The <ns-bindings> Element . . . . . . . . . . . . . . . . 5 3.3 The <ns-bindings> Element . . . . . . . . . . . . . . . . 5
3.4 The <filter> Element . . . . . . . . . . . . . . . . . . . 6 3.4 The <filter> Element . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 37 skipping to change at page 2, line 35
3.5.2 The <exclude> Element . . . . . . . . . . . . . . . . 8 3.5.2 The <exclude> Element . . . . . . . . . . . . . . . . 8
3.5.3 The 'type' Attribute . . . . . . . . . . . . . . . . . 8 3.5.3 The 'type' Attribute . . . . . . . . . . . . . . . . . 8
3.6 The <trigger> Element . . . . . . . . . . . . . . . . . . 8 3.6 The <trigger> Element . . . . . . . . . . . . . . . . . . 8
3.6.1 The <changed> Element . . . . . . . . . . . . . . . . 9 3.6.1 The <changed> Element . . . . . . . . . . . . . . . . 9
3.6.1.1 The 'from' Attribute . . . . . . . . . . . . . . . 9 3.6.1.1 The 'from' Attribute . . . . . . . . . . . . . . . 9
3.6.1.2 The 'to' Attribute . . . . . . . . . . . . . . . . 9 3.6.1.2 The 'to' Attribute . . . . . . . . . . . . . . . . 9
3.6.1.3 The 'by' Attribute . . . . . . . . . . . . . . . . 9 3.6.1.3 The 'by' Attribute . . . . . . . . . . . . . . . . 9
3.6.1.4 Combination of Attributes . . . . . . . . . . . . 10 3.6.1.4 Combination of Attributes . . . . . . . . . . . . 10
3.6.2 The <added> Element . . . . . . . . . . . . . . . . . 10 3.6.2 The <added> Element . . . . . . . . . . . . . . . . . 10
3.6.3 The <removed> Element . . . . . . . . . . . . . . . . 10 3.6.3 The <removed> Element . . . . . . . . . . . . . . . . 10
4. Syntax for Referencing XML Items and Making Logical 4. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 10
Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Syntax for Referencing XML Items and Making Logical
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Filter Criteria Using <what> Element . . . . . . . . . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Filter Criteria Using <trigger> Element . . . . . . . . . 13 6.1 Filter Criteria Using <what> Element . . . . . . . . . . . 13
5.3 Filter Criteria Using <what> and <trigger> Elements . . . 13 6.2 Filter Criteria Using <trigger> Element . . . . . . . . . 14
5.4 Content Filter Using Namespaces . . . . . . . . . . . . . 14 6.3 Filter Criteria Using <what> and <trigger> Elements . . . 14
5.5 Content Filter Using Only <include> Elements . . . . . . . 15 6.4 Content Filter Using Namespaces . . . . . . . . . . . . . 15
5.6 Two Content Filters as Filter Criteria . . . . . . . . . . 15 6.5 Content Filter Using Only <include> Elements . . . . . . . 16
6. XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 16 6.6 Two Content Filters as Filter Criteria . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1 application/simple-filter+xml MIME TYPE . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.2 URN Sub-Namespace Registration for 9.1 application/simple-filter+xml MIME TYPE . . . . . . . . . 20
urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 20 9.2 URN Sub-Namespace Registration for
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 9.3 Schema Registration . . . . . . . . . . . . . . . . . . . 21
10.2 Informative References . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24 11.1 Normative References . . . . . . . . . . . . . . . . . . . 22
11.2 Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
The SIP event notification framework [2] describes the usage of the The SIP event notification framework [2] describes the usage of the
Session Initiation Protocol (SIP) for subscriptions and notifications Session Initiation Protocol (SIP) for subscriptions and notifications
of changes to a state of a resource. The document does not describe of changes to a state of a resource. The document does not describe
a mechanism of how filtering of event notification information can a mechanism of how filtering of event notification information can
be achieved. be achieved.
Filtering is a mechanism for defining the preferred notification Filtering is a mechanism for defining the preferred notification
skipping to change at page 4, line 25 skipping to change at page 4, line 25
specifying the rules for when that information should be delivered. specifying the rules for when that information should be delivered.
The filtering mechanism is expected to be particularly valuable and The filtering mechanism is expected to be particularly valuable and
primarily applicable to users of mobile wireless access devices. The primarily applicable to users of mobile wireless access devices. The
characteristics of the devices typically include high latency, low characteristics of the devices typically include high latency, low
bandwidth, low data processing capabilities, small display, and bandwidth, low data processing capabilities, small display, and
limited battery power. Such devices can benefit from the ability to limited battery power. Such devices can benefit from the ability to
filter the amount of information generated at the source of the event filter the amount of information generated at the source of the event
notification. However, implementers need to be aware of the notification. However, implementers need to be aware of the
computational burden on the source of the event notification. This computational burden on the source of the event notification. This
is discussed further in Section 7. is discussed further in Section 8.
The structure of the filter criteria is described using the XML The structure of the filter criteria is described using the XML
Schema. The filter criteria is presented as an XML document. The Schema. The filter criteria is presented as an XML document. The
XML document contains the user's preference when notifications are to 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" be sent to it and what they are to contain. The scope of the "when"
part is triggering. part is triggering.
The triggering is defined as enabling a subscriber to specify The triggering is defined as enabling a subscriber to specify
triggering rules for notifications where the criteria are based on triggering rules for notifications where the criteria are based on
changes of the event package [2] specific state information, e.g., changes of the event package [2] specific state information, e.g.,
skipping to change at page 5, line 51 skipping to change at page 5, line 51
or from the protocol that usually carries it. or from the protocol that usually carries it.
The <filter-set> element may contain one <ns-bindings> elements. The <filter-set> element may contain one <ns-bindings> elements.
The <filter-set> element contains one or more <filter> elements. The <filter-set> element contains one or more <filter> elements.
3.3 The <ns-bindings> Element 3.3 The <ns-bindings> Element
The <ns-bindings> element is used to bind namespaces to local The <ns-bindings> element is used to bind namespaces to local
prefixes used in expressions that select elements or attributes using prefixes used in expressions that select elements or attributes using
the syntax in Section 4. Those prefixes apply to the <include>, the syntax in Section 5. Those prefixes apply to the <include>,
<exclude>, <changed>, <added> and <removed> elements. <exclude>, <changed>, <added> and <removed> elements.
The <ns-bindings> element contains one or more <ns-binding> elements. The <ns-bindings> element contains one or more <ns-binding> elements.
Each <ns-binding> element has a 'prefix' attribute. The value of the Each <ns-binding> element has a 'prefix' attribute. The value of the
'prefix' attribute is a prefix used to qualify the elements pointed 'prefix' attribute is a prefix used to qualify the elements pointed
to by the expression. The <ns-binding> element also has a 'urn' to by the expression. The <ns-binding> element also has a 'urn'
attribute that identifies the namespace that the prefix represents. attribute that identifies the namespace that the prefix represents.
3.4 The <filter> Element 3.4 The <filter> Element
skipping to change at page 7, line 45 skipping to change at page 7, line 45
addition to including the elements identified with the <include> addition to including the elements identified with the <include>
element value, all other mandatory XML elements and/or attributes element value, all other mandatory XML elements and/or attributes
must be incorporated in the resulting XML document in order to make must be incorporated in the resulting XML document in order to make
it valid. This, in practice, means that a subscriber defining a it valid. This, in practice, means that a subscriber defining a
filter only needs to <include> optional elements and/or attributes, filter only needs to <include> optional elements and/or attributes,
but may <include> mandatory elements and/or attributes as well. but may <include> mandatory elements and/or attributes as well.
There are also cases where a filter selects an attribute that belongs There are also cases where a filter selects an attribute that belongs
to an optional element. In this case, the optional element needs to to an optional element. In this case, the optional element needs to
appear in the resulting XML document. appear in the resulting XML document.
The syntax defined in Section 4 (see the definition of "selection".) The syntax defined in Section 5 (see the definition of "selection".)
MUST be used. The following example selects the <status> element MUST be used. The following example selects the <basic> element
defined in the PIDF [13]. This results in the selection of the defined in the PIDF [13]. This results in the selection of the
<basic> element as well as all the ancestors. I.e. <status> and <basic> element as well as all the ancestors. I.e. <status> and
<tuple>. <tuple>.
<include type="xpath">/presence/tuple/status/basic</include>. <include type="xpath">/presence/tuple/status/basic</include>.
3.5.2 The <exclude> Element 3.5.2 The <exclude> Element
The <exclude> element is used to define exceptions to the set of XML The <exclude> element is used to define exceptions to the set of XML
elements and/or attributes selected by the <include> elements. Thus, elements and/or attributes selected by the <include> elements. Thus,
skipping to change at page 8, line 26 skipping to change at page 8, line 26
Note that the resulting XML document MUST be valid. Therefore, if Note that the resulting XML document MUST be valid. Therefore, if
the step in applying the <exclude> element value to an XML document the step in applying the <exclude> element value to an XML document
results in an invalid document according to the schema, that step results in an invalid document according to the schema, that step
MUST be reveresed resulting in the elements and/or attributes being MUST be reveresed resulting in the elements and/or attributes being
re-introduced into the resulting XML document, with their previous re-introduced into the resulting XML document, with their previous
values, in order to make it valid. This, in practice, means that a values, in order to make it valid. This, in practice, means that a
subscriber defining a filter only needs to <exclude> optional subscriber defining a filter only needs to <exclude> optional
elements and/or attributes, but SHOULD NOT <exclude> mandatory elements and/or attributes, but SHOULD NOT <exclude> mandatory
elements and/or attributes. elements and/or attributes.
The syntax MUST follow Section 4. The syntax MUST follow Section 5.
3.5.3 The 'type' Attribute 3.5.3 The 'type' Attribute
The 'type' attribute is used to describe the value of the <include> The 'type' attribute is used to describe the value of the <include>
and <exclude> elements. The following values are pre-defined: and <exclude> elements. The following values are pre-defined:
"xpath" and "namespace". The 'type' attribute is optional, and, if "xpath" and "namespace". The 'type' attribute is optional, and, if
omitted, the default value is "xpath". omitted, the default value is "xpath".
The "xpath" value is used when the <include> or <exclude> element The "xpath" value is used when the <include> or <exclude> element
contains a value following the syntax in Section 4 that selects and contains a value following the syntax in Section 5 that selects an
element or an attribute. element or an attribute.
The "namespace" value is used when the <include> or <exclude> element The "namespace" value is used when the <include> or <exclude> element
contains a value of a namespace. The value is the URI of the contains a value of a namespace. The value is the URI of the
namespace. The resulting XML document is comprised of the elements namespace. The resulting XML document is comprised of the elements
defined within the namespace. defined within the namespace.
3.6 The <trigger> Element 3.6 The <trigger> Element
The <trigger> element is used to identify the package specific The <trigger> element is used to identify the package specific
changes that a resource has to encounter before the content is changes that a resource has to encounter before the content is
delivered to the subscriber. It can appear more than once in a delivered to the subscriber. It can appear more than once in a
filter document. Multiple appearances of this element denotes the <filter> element. Multiple appearances of this element denotes the
"OR" operation. This means that updates to a resource that satisfy "OR" operation. This means that updates to a resource that satisfy
any of the <trigger> elements criteria constitute the content to be any of the <trigger> elements criteria constitute the content to be
delivered. delivered.
The <trigger> element MAY contain the <changed> element, the <added> The <trigger> element MAY contain the <changed> element, the <added>
element or the <removed>, but MUST contain at least one of the three element or the <removed>, but MUST contain at least one of the three
elements. Any combination of the 3 elements is possible. Multiple elements. Any combination of the 3 elements is possible. Multiple
appearances of those element within a <trigger> element denotes the appearances of those elements within a <trigger> element denotes the
"AND" operation. This means that updates to a resource that satisfy "AND" operation. This means that updates to a resource that satisfy
ALL of the <changed>, <added> and <removed> elements' criteria within ALL of the <changed>, <added> and <removed> elements' criteria within
the <trigger> element constitute the content to be delivered. the <trigger> element constitute the content to be delivered.
3.6.1 The <changed> Element 3.6.1 The <changed> Element
The <changed> element is used to identify the XML element or The <changed> element is used to identify the XML element or
attribute, from the package specific XML document, whose value MUST attribute, from the package specific XML document, whose value MUST
change, compared to the "previous XML document", in order to activate change, compared to the "previous XML document", in order to activate
the trigger and cause the content to be delivered. Previous XML the trigger and cause the content to be delivered. Previous XML
document in this context refers to the last XML document that was document in this context refers to the last XML document that was
selected for delivery to that specific subscriber before any filter selected for delivery to that specific subscription before any filter
was applied to it. The XML element or attribute MUST be expressed was applied to it. The XML element or attribute MUST be expressed
using the syntax defined in Section 4 for the "reference" ABNF. using the syntax defined in Section 5 for the "reference" ABNF.
The <changed> element MAY contain the 'from' attribute, 'to' The <changed> element MAY contain the 'from' attribute, 'to'
attribute, 'by' attribute, or any combination of the three. The attribute, 'by' attribute, or any combination of the three. The
absence of all those attributes means a change of any sort to 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 value of the element or attribute activates the trigger. An update
to the element or attribute value with an identical value is not a to the element or attribute value with an identical value is not a
change. change.
Comparison of a change is done the element or attribute's lexical Comparison of a change is done the element or attribute's lexical
rules. rules.
skipping to change at page 10, line 28 skipping to change at page 10, line 28
3.6.2 The <added> Element 3.6.2 The <added> Element
The <added> element triggers content delivery when the XML element it The <added> element triggers content delivery when the XML element it
identifies has been added to the document being filtered (that is, identifies has been added to the document being filtered (that is,
this instance of that element appears in the current document, but this instance of that element appears in the current document, but
not the previous document). It can be used, for example, to learn not the previous document). It can be used, for example, to learn
of new services and/or capabilities subscribed to by the user, or of new services and/or capabilities subscribed to by the user, or
services and/or capabilities that the user has now allowed the services and/or capabilities that the user has now allowed the
subscriber to see. The XML element or attribute MUST be expressed subscriber to see. The XML element or attribute MUST be expressed
using the syntax defined in Section 4 for the "reference" ABNF. using the syntax defined in Section 5 for the "reference" ABNF.
Note that if a filter includes both the content filter (<what>) part Note that if a filter includes both the content filter (<what>) part
and the <added> element then the definitions of the <what> part and the <added> element then the definitions of the <what> part
SHOULD cover also the added elements, or otherwise the content is SHOULD cover also the added elements, or otherwise the content is
delivered without the items defined in the <added> element. delivered without the items defined in the <added> element.
3.6.3 The <removed> Element 3.6.3 The <removed> Element
The <removed> element triggers content delivery when the XML element The <removed> element triggers content delivery when the XML element
it identifies has been removed from the document being filtered (that it identifies has been removed from the document being filtered (that
is, this instance of that element appeared in the previous document, is, this instance of that element appeared in the previous document,
but not the this document). The XML element or attribute MUST be but not the this document). The XML element or attribute MUST be
expressed using the syntax defined in Section 4 for the "reference" expressed using the syntax defined in Section 5 for the "reference"
ABNF. ABNF.
4. Syntax for Referencing XML Items and Making Logical Expressions 4. XML Schema Extensibility
The filter-set document is meant to be extended. An extension takes
place by defining a new set of elements in a new namespace, governed
by a new schema. Every extension MUST have an appropriate XML
namespace assigned to it. The XML namespace of the extension MUST be
different from the namespaces defined in this specification. The
extension MUST NOT change the syntax or semantics of the schemas
defined in this document. All XML tags and attributes that are part
of the extension MUST be appropriately qualified so as to place them
within that namespace and MUST be designed such that receivers can
safely ignore such extensions.
This specification defines explict places where new elements or
attributes from an extension can be placed. These are explicitly
indicated in the schemas by the <any> and <anyAttribute> elements.
Extensions to this specification MUST specify where their elements
can be placed within the document.
As a result, a document that contains extensions will require
multiple schemas in order to determine its validity - a schema
defined in this document, along with those defined by extensions
present in the document. Because extensions occur by adding new
elements and attributes governed by new schemas, the schemas defined
in this document are fixed and would only be changed by a revision to
this specification. Such a revision, should it take place, would
endeavor to allow documents compliant to the previous schema to
remain compliant to the new one. As a result, the schemas defined
here don't provide explicit schema versions, as this is not expected
to be needed.
5. Syntax for Referencing XML Items and Making Logical Expressions
The ABNF [10] is used to describe the syntax for the expressions. The ABNF [10] is used to describe the syntax for the expressions.
The syntax is defined to be XPATH [9] compatible, but has only a The syntax is defined to be XPATH [9] compatible, but has only a
restricted set of capabilities of the XPATH. More information about restricted set of capabilities of the XPATH. More information about
the meaning of the items of the syntax can be found in [9]. The 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 "abbreviated syntax" of the "node test" is used in the references
("reference"). The expression in the syntax relates to the ("reference"). The expression in the syntax relates to the
predicate, comparison and logical expressions of the XPATH. If an predicate, comparison and logical expressions of the XPATH. If an
XPATH expression evaluates to more than one element at a certain XPATH expression evaluates to more than one element at a certain
step, the filter applies to all the elements that are evaluated. step, the filter applies to all the elements that are evaluated.
skipping to change at page 11, line 38 skipping to change at page 12, line 33
value = <any sequence of data supported by XML as a value of the value = <any sequence of data supported by XML as a value of the
XML element and/or attribute> XML element and/or attribute>
When identifying XML elements or attributes, the value may consist of When identifying XML elements or attributes, the value may consist of
two parts: the XML element/attribute selector and the condition two parts: the XML element/attribute selector and the condition
(comparison and logical expressions). The XML element selector (comparison and logical expressions). The XML element selector
appears first followed by the condition part in square brackets. In appears first followed by the condition part in square brackets. In
the XML element selector part the XML elements may be referenced by the XML element selector part the XML elements may be referenced by
giving the full hierarchical path as: "/presence/tuple/status/basic", giving the full hierarchical path as: "/presence/tuple/status/basic",
or by denoting the selection to cover any hierarchical level by its or by denoting the selection to cover any hierarchical level by its
name as: "/presence/tuple/status/basic" or using the wildcard "*" name as: "//tuple/status/basic" or using the wildcard "*" denoting
denoting any value in a certain level as "/*/watcher". any value in a certain level as "/*/watcher".
Example references are listed as follows: Example references are listed as follows:
o Selecting an element by using an XML element as a condition: o Selecting an element by using an XML element as a condition:
* //*[status/basic="open"] * //*[status/basic="open"]
* /presence/tuple[*/basic="open"] * /presence/tuple[*/basic="open"]
o Selecting an element by using XML attributes as a condition : o Selecting an element by using XML attributes as a condition :
skipping to change at page 12, line 32 skipping to change at page 13, line 26
When evaluating XPath location steps, namespace expansion follows When evaluating XPath location steps, namespace expansion follows
XPath 1.0 [9] semantics, i.e. if the QName does not have a prefix 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 then the namespace URI in the expanded name is null. With
non-default namespaces, expansion is done according to the given non-default namespaces, expansion is done according to the given
<ns-bindings> definitions. When there's a default namespace used in <ns-bindings> definitions. When there's a default namespace used in
the document, <ns-binding> element SHOULD be used to define an equal 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 URI with some prefix in order to have a valid XPath evaluation in
location steps. location steps.
5. Examples 6. Examples
The XML Schema for the XML document examples is specified in the The XML Schema for the XML document examples is specified in the
Section 6. Section 7.
5.1 Filter Criteria Using <what> Element 6.1 Filter Criteria Using <what> Element
A user wishes to get to know his friend's availability and A user wishes to get to know his friend's availability and
willingness for messaging (SMS, IM and MMS) in order to know whether 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 friend is able to receive a message, the address to contact and
the type of the message to be used. the type of the message to be used.
This example shows how to define a content filter. The <basic> This example shows how to define a content filter. The <basic>
element as well as all parent elements are selected based on a element as well as all parent elements are selected based on a
condition defined by a logical expression. The condition is: <class> condition defined by a logical expression. The condition is: <class>
elements that have a value "MMS", "SMS" or "IM". elements that have a value "MMS", "SMS" or "IM".
The <class> element is defined in [14] as an extension to PIDF [13]. The <class> element is defined in [14] as an extension to PIDF [13].
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" <ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/> urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@domain.com"> <filter id="123" uri="sip:presentity@example.com">
<what> <what>
<include type="xpath"> <include type="xpath">
/pidf:presence/pidf:tuple[rpid:class="IM" or rpid:class="SMS" /pidf:presence/pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:status/pidf:basic or rpid:class="MMS"]/pidf:status/pidf:basic
</include> </include>
</what> </what>
</filter> </filter>
</filter-set> </filter-set>
5.2 Filter Criteria Using <trigger> Element 6.2 Filter Criteria Using <trigger> Element
A user requires to get informed when his colleague becomes available A user requires to get informed when his colleague becomes available
by some communication mean(s). The user gets the full presence state by some communication mean(s). The user gets the full presence state
of the colleague when a certain PIDF [13] tuple <basic> status of the colleague when a certain PIDF [13] tuple <basic> status
changes from 'CLOSED' to 'OPEN'. changes from 'CLOSED' to 'OPEN'.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@domain.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<changed from="CLOSED" to="OPEN"> <changed from="CLOSED" to="OPEN">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic /pidf:presence/pidf:tuple/pidf:status/pidf:basic
</changed> </changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
5.3 Filter Criteria Using <what> and <trigger> Elements 6.3 Filter Criteria Using <what> and <trigger> Elements
A user wishes to get information about pending and waiting A user wishes to get information about pending and waiting
subscriptions in order to be able to authorise watchers to see his subscriptions in order to be able to authorise watchers to see his
presence information. presence information.
The filter selects watcher information notifications [16] to be sent The filter selects watcher information notifications [16] to be sent
when a subscription status has changed to "pending" or "waiting". In when a subscription status has changed to "pending" or "waiting". In
the notification, only the watchers that have a status of "pending" the notification, only the watchers that have a status of "pending"
or "waiting" are included. or "waiting" are included.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="wi" <ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/> urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@domain.com"> <filter id="123" uri="sip:presentity@example.com">
<what> <what>
<include> <include>
/wi:watcherinfo/wi:watcher-list/wi:watcher[@status="pending" /wi:watcherinfo/wi:watcher-list/wi:watcher[@status="pending"
or @status="waiting"] or @status="waiting"]
</include> </include>
</what> </what>
<trigger> <trigger>
<changed to="pending"> <changed to="pending">
/wi:watcherinfo/wi:watcher-list/wi:watcher/@status /wi:watcherinfo/wi:watcher-list/wi:watcher/@status
</changed> </changed>
</trigger> </trigger>
<trigger> <trigger>
<changed to="waiting"> <changed to="waiting">
/wi:watcherinfo/wi:watcher-list/wi:watcher/@status /wi:watcherinfo/wi:watcher-list/wi:watcher/@status
</changed> </changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
5.4 Content Filter Using Namespaces 6.4 Content Filter Using Namespaces
A user turns her terminal on and the terminal automatically fetches A user turns her terminal on and the terminal automatically fetches
general presence status and information about communication means general presence status and information about communication means
from a certain pre-defined set of her buddies. from a certain pre-defined set of her buddies.
The filter is defined to select XML elements belonging to the pidf The filter is defined to select XML elements belonging to the pidf
namespace. namespace.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<filter id="123" uri="sip:buddylist@domain.com"> <filter id="123" uri="sip:buddylist@example.com">
<what> <what>
<include type="namespace"> <include type="namespace">
urn:ietf:params:xml:ns:pidf urn:ietf:params:xml:ns:pidf
</include> </include>
</what> </what>
</filter> </filter>
</filter-set> </filter-set>
5.5 Content Filter Using Only <include> Elements 6.5 Content Filter Using Only <include> Elements
A user wants to know if a group of his friends are available for A user wants to know if a group of his friends are available for
gaming. He orders notifications about the current status and future gaming. He orders notifications about the current status and future
changes of the game specific presence information. changes of the game specific presence information.
This filter is defined to select the game specific tuple to be This filter is defined to select the game specific tuple to be
delivered. delivered.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" > <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" >
skipping to change at page 15, line 32 skipping to change at page 16, line 32
<filter id="123"> <filter id="123">
<what> <what>
<include> <include>
/pidf:presence/pidf:tuple/ /pidf:presence/pidf:tuple/
pidf:status[game-ext:label="game-X"] pidf:status[game-ext:label="game-X"]
</include> </include>
</what> </what>
</filter> </filter>
</filter-set> </filter-set>
5.6 Two Content Filters as Filter Criteria 6.6 Two Content Filters as Filter Criteria
The user is interested in getting up-to-date information about the The user is interested in getting up-to-date information about the
communication means and contact addresses of his friends. The user communication means and contact addresses of his friends. The user
wants to get also more information (e.g. location) about one of the 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 friends in the list named Bob. The PIDF element <note> is filtered
out, i.e. excluded. The list was predefined as buddies@domain.com. out, i.e. excluded. The list was predefined as buddies@example.com.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid" <ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/> urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
</ns-bindings> </ns-bindings>
<filter id="8439" uri="sip:buddies@domain.com"> <filter id="8439" uri="sip:buddies@example.com">
<what> <what>
<include> <include>
/pidf:presence/pidf:tuple[rpid:class="service"]/pidf:status/ /pidf:presence/pidf:tuple[rpid:class="service"]/pidf:status/
pidf:basic pidf:basic
</include> </include>
</what> </what>
</filter> </filter>
<filter id="999" uri="sip:bob@domain.com"> <filter id="999" uri="sip:bob@example.com">
<what> <what>
<include type="namespace"> <include type="namespace">
urn:ietf:params:xml:ns:pidf urn:ietf:params:xml:ns:pidf
</include> </include>
<exclude> <exclude>
/pidf:presence/pidf:tuple/pidf:note /pidf:presence/pidf:tuple/pidf:note
</exclude> </exclude>
</what> </what>
</filter> </filter>
</filter-set> </filter-set>
6. XML Schema for Filter Criteria 7. XML Schema for Filter Criteria
XML Schema Implementation (Normative) XML Schema Implementation (Normative)
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter" <xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
skipping to change at page 19, line 16 skipping to change at page 20, line 16
use="optional"/> use="optional"/>
<xs:attribute name="by" type="xs:decimal" <xs:attribute name="by" type="xs:decimal"
use="optional"/> use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/> <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
7. Security Considerations 8. Security Considerations
The filters in the body in a SIP message has a significant effect on 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, the ways in which the request is handled at a server. As a result,
it is especially important that messages containing this extension be it is especially important that messages containing this extension be
authenticated and authorised. authenticated and authorised. Authentication can be achieved using
the Digest Authentication mechanism described in [12]. The
authorisation decision is made based on the permissions that the
resource (notifier) has given to the watcher. An example of such
auhorisation policy can be found in [18].
Requests can reveal sensitive information about a UA's capabilities. Requests can reveal sensitive information about a UA's capabilities.
If this information is sensitive, it SHOULD be encrypted using SIP If this information is sensitive, it SHOULD be encrypted using SIP
S/MIME capabilities [11]. S/MIME capabilities [11].
All filtering related security measures discussed in [2] MUST be All filtering related security measures discussed in [2] MUST be
followed along with package specific security. followed along with package specific security.
It is important to note that a flitered document located at a 9. IANA Considerations
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 This document registers a new MIME type
"application/simple-filter+xml", and registers a new XML namespace. "application/simple-filter+xml", and registers a new XML namespace.
This specification follows the guidelines of RFC3023 [7]. This specification follows the guidelines of RFC3023 [7].
8.1 application/simple-filter+xml MIME TYPE 9.1 application/simple-filter+xml MIME TYPE
MIME media type: application MIME media type: application
MIME subtype name: simple-filter+xml MIME subtype name: simple-filter+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [7]. specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [7]. application/xml as specified in RFC 3023 [7].
Security considerations: See section 10 of RFC 3023 [7] and section Security considerations: See section 10 of RFC 3023 [7] and section
Section 7 of this document. Section 8 of this document.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP based Event notification framework and its used to support SIP based Event notification framework and its
packages. packages.
Additional information: Additional information:
Magic number: None Magic number: None
File extension: .cl or .xml File extension: .cl or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@nokia.com) (hisham.khartabil@telio.no)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF Author/change controller: The IETF
8.2 URN Sub-Namespace Registration for 9.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:simple-filter urn:ietf:params:xml:ns:simple-filter
This section registers a new XML namespace, as per guidelines in URN This section registers a new XML namespace, as per guidelines in the
document [4]. IETF XML Registry [4].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:simple-filter. urn:ietf:params:xml:ns:simple-filter.
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@nokia.com) (hisham.khartabil@telio.no)
XML:
BEGIN 9.3 Schema Registration
<?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 This section registers a new XML schema per the procedures in [4].
URI: urn:ietf:params:xml:ns:simple-filter
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@telio.no).
The XML for this schema can be found as the sole content of
Section 7.
10. Acknowledgements
The authors would like to thank Jonathan Rosenberg, Henning The authors would like to thank Jonathan Rosenberg, Henning
Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla, Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla,
Miguel-Angel Garcia Martin, Mary Barnes, Paul Kyzivat, Robert Sparks Miguel-Angel Garcia Martin, Mary Barnes, Paul Kyzivat, Robert Sparks
and Elwyn Davies for their valuable input and comments. and Elwyn Davies for their valuable input and comments.
10. References 11. References
10.1 Normative References 11.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[3] Khartabil, H., "Functional Description of Event Notification [3] Khartabil, H., "Functional Description of Event Notification
Filtering", draft-simple-event-filter-funct-04.txt, January Filtering", draft-simple-event-filter-funct-05.txt, February
2005. 2005.
[4] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [4] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[5] Moats, R., "The URN Syntax", RFC 2141, May 1997. [5] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, [6] Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[7] Murata, M., "XML Media Types", RFC 3023, March 1997. [7] Murata, M., "XML Media Types", RFC 3023, March 1997.
[8] Bray, T., "Exensible Markup Language (XML) 1.0 (Second [8] Bray, T., "Exensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000. Edition)", W3C CR CR-xml11-20011006, October 2000.
[9] Clark, J., "XML Path Language (XPath) Version 1.0", W3C REC [9] Clark, J., "XML Path Language (XPath) Version 1.0", W3C REC
REC-xpath-19991116, November 1999. REC-xpath-19991116, November 1999.
[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", [10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
RFC 2234, November 1997. RFC 2234, November 1997.
[11] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [11] Ramsdell, B., "S/MIME Version 3 Message Specification",
2633, June 1999. RFC 2633, June 1999.
10.2 Informative References 11.2 Informative References
[12] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, [12] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002. "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[13] Sugano, H., "Presence Information Data Format", RFC 3863, [13] Sugano, H., "Presence Information Data Format", RFC 3863,
Auguest 2004. Auguest 2004.
[14] Schulzrinne, H., "RPID -- Rich Presence Information Data [14] Schulzrinne, H., "RPID -- Rich Presence Information Data
Format", draft-ietf-simple-rpid-00.txt (work in progress), May Format", draft-ietf-simple-rpid-00.txt (work in progress), May
2004. 2004.
[15] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions [15] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
for Presence", RFC 3856, July 2004. for Presence", RFC 3856, July 2004.
[16] Rosenberg, J., "An Extensible Markup Language (XML) Based [16] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, July 2004. Format for Watcher Information", RFC 3858, July 2004.
[17] Roach, A., "A Session Initiation Protocol (SIP) Event [17] Roach, A., "A Session Initiation Protocol (SIP) Event
Notification Extension for Resource Lists", Notification Extension for Resource Lists",
draft-ietf-simple-event-list-04.txt, June 2003. draft-ietf-simple-event-list-04.txt, June 2003.
[18] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-01, April 2005.
Authors' Addresses Authors' Addresses
Hisham Khartabil Hisham Khartabil
Telio Telio
P.O. Box 1203 Vika P.O. Box 1203 Vika
Oslo Oslo
Norway Norway
Phone: +47 2167 3544 Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no Email: hisham.khartabil@telio.no
Eva Leppanen Eva Leppanen
Nokia Nokia
P.O BOX 785 P.O BOX 785
Tampere Tampere
Finland Finland
Phone: +358 7180 77066 Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com Email: eva-maria.leppanen@nokia.com
Mikko Lonnfors Mikko Lonnfors
Nokia Nokia
Itamerenkatu 00180 Itamerenkatu 00180
Helsinki Helsinki
Finland Finland
Phone: + 358 50 4836402 Phone: + 358 50 4836402
EMail: mikko.lonnfors@nokia.com Email: mikko.lonnfors@nokia.com
Jose Costa-Requena Jose Costa-Requena
Nokia Nokia
P.O. Box 321 P.O. Box 321
FIN-00045 NOKIA GROUP FIN-00045 NOKIA GROUP
FINLAND FINLAND
Phone: +358 71800 8000 Phone: +358 71800 8000
EMail: jose.costa-requena@nokia.com Email: jose.costa-requena@nokia.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 59 change blocks. 
115 lines changed or deleted 138 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/