An Extensible Markup Language (XML)-Based Format for Event Notification Filtering
Extracted elements (29)
Extensions are accommodated by defining new elements in new XML namespaces governed by separate schemas, rather than versioning the base schema. The base schema uses <any> and <anyAttribute> to designate explicit extension points, and the schema does not carry a version attribute because backward compatibility across revisions is assumed.
The expression syntax in Section 5 is defined to be XPath-compatible but deliberately restricted, providing only a subset of XPath capabilities. This limits complexity while retaining sufficient expressiveness for filtering PIDF and similar presence documents.
The filtering mechanism is primarily targeted at mobile wireless devices characterized by high latency, low bandwidth, low processing capability, and limited battery power. Filtering at the event source reduces the amount of information transmitted to the device, though implementers must consider the computational burden placed on the notifier.
A <filter> element MUST contain either the <what> element or the <trigger> element when the filter is being enabled for the first time. When a filter is disabled or re-enabled, the <what> and <trigger> elements MAY be omitted.
A simple-filter document MUST be well formed and MUST be valid according to schemas applicable to the XML document. It MUST be based on XML 1.0 and MUST be encoded using UTF-8.
A <trigger> element MUST contain at least one of the <changed>, <added>, or <removed> child elements. Any combination of the three is permitted.
All XML elements or attributes referenced in <changed>, <added>, and <removed> MUST be expressed using the 'reference' ABNF syntax defined in Section 5 (an XPath-compatible restricted syntax).
Any transport protocol (e.g., SIP) that carries a simple-filter document and also carries payload type information MUST identify the payload as MIME type 'application/simple-filter+xml'.
Every extension to the simple-filter schema MUST have an appropriate XML namespace assigned to it, MUST NOT change the syntax or semantics of the base schemas, and MUST be designed so that receivers can safely ignore the extension elements.
The resulting XML document produced by applying <include> and <exclude> filters MUST be valid. If applying an <exclude> element value results in an invalid document, that step MUST be reversed, re-introducing the excluded elements with their previous values.
The 'selection' and 'reference' ABNF productions defined in Section 5 MUST be used in <include>, <exclude>, <changed>, <added>, and <removed> elements. When evaluating XPath location steps, if no prefix is present, the namespace URI is null per XPath 1.0 semantics.
The value of the 'id' attribute MUST be unique within the <filter-set> element. The 'uri' attribute and the 'domain' attribute MUST NOT appear together in the same <filter> element.
When a default namespace is used in the filtered document, the <ns-binding> element SHOULD be used to define an equal URI with a prefix in order to have a valid XPath evaluation in location steps.
The <added> element triggers content delivery when the identified XML element has been added to the current document compared to the previous document. The <removed> element triggers delivery when the identified element has been removed from the current document.
The <changed> element identifies an XML element or attribute whose value must change from the previous notification document to activate the trigger. It supports optional 'from', 'to', and 'by' attributes to constrain the nature of the change; 'by' applies only to numeric values and specifies a required delta.
The <filter> element represents an individual filter and carries a required 'id' attribute (unique within <filter-set>), optional 'uri' (resource URI), optional 'domain', optional 'remove' (Boolean, default false), and optional 'enabled' (Boolean, default true) attributes.
The filter expression syntax is an ABNF-defined, XPath 1.0-compatible but restricted grammar. It supports element/attribute selection via hierarchical paths, wildcards, and predicates (comparison and logical expressions), but only a restricted subset of full XPath capabilities.
The <ns-bindings> element binds namespace URIs to local prefixes used in XPath-like expressions within <include>, <exclude>, <changed>, <added>, and <removed> elements. Each child <ns-binding> has a required 'prefix' attribute and a required 'urn' attribute.
The simple-filter document is an XML 1.0 document rooted at <filter-set>, which contains an optional <ns-bindings> element and one or more <filter> elements. The optional 'package' attribute on <filter-set> identifies the event package to which the filter criteria apply.
The <trigger> element identifies package-specific state changes that must occur before content is delivered. Multiple <trigger> elements within a <filter> are OR-ed; multiple child elements within one <trigger> are AND-ed.
The 'type' attribute on <include> and <exclude> elements accepts values 'xpath' (default) or 'namespace'. When 'namespace' is used, the element value is treated as a namespace URI and all elements in that namespace are selected.
The <what> element specifies which content should be delivered to the subscriber. It may contain one or more <include> elements (additive) and one or more <exclude> elements (subtractive), describing rules for constructing the resulting XML document.
This document registers the MIME media type 'application/simple-filter+xml' with IANA for use as the payload type for simple-filter XML documents. Optional parameters follow application/xml per RFC 3023; file extensions are .cl or .xml.
This document registers the XML namespace URN 'urn:ietf:params:xml:ns:simple-filter' in the IETF XML Registry per RFC 3688, to be used as the namespace identifier for elements defined in this specification.
This document registers the XML schema for filter criteria under URI 'urn:ietf:params:xml:ns:simple-filter' in the IETF XML Registry. The schema content is normatively defined in Section 7 of the RFC.
All filtering-related security measures defined in RFC 3265 (SIP-Specific Event Notification) MUST be followed, along with any package-specific security requirements.
Filter documents carried in SIP messages significantly affect server behavior, so SIP messages containing filters MUST be authenticated and authorized. Authentication SHOULD use SIP Digest Authentication; authorization is based on permissions granted by the notifier to the watcher.
Subscription requests carrying filter criteria can reveal sensitive information about a UA's capabilities. If this information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities.
The simple-filter document is encoded as an XML 1.0 document using UTF-8, identified by MIME type 'application/simple-filter+xml', with namespace 'urn:ietf:params:xml:ns:simple-filter'. The root element is <filter-set>, which may contain one <ns-bindings> and one or more <filter> children.