idnits 2.17.1 

draft-khartabil-simple-filter-format-01.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack a Security Considerations section.

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  ** There are 32 instances of too long lines in the document, the longest
     one being 51 characters in excess of 72.

  ** There are 110 instances of lines with control characters in the document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords. 

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 24, 2003) is 7489 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-10) exists of
     draft-ietf-simple-rpid-00

  == Outdated reference: A later version (-07) exists of
     draft-ietf-simple-cipid-00

  ** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665)

  == Outdated reference: A later version (-07) exists of
     draft-ietf-simple-event-list-04

  == Outdated reference: A later version (-03) exists of
     draft-ietf-simple-pres-filter-reqs-02

  -- Possible downref: Normative reference to a draft: ref. '9' 

  == Outdated reference: A later version (-01) exists of
     draft-ietf-simple-winfo-filter-reqs-00

  -- Possible downref: Normative reference to a draft: ref. '10' 

  == Outdated reference: A later version (-01) exists of
     draft-khartabil-simple-filter-funct-00

  -- Possible downref: Normative reference to a draft: ref. '11' 

  == Outdated reference: A later version (-05) exists of
     draft-mealling-iana-xmlns-registry-04

  ** Obsolete normative reference: RFC 2141 (ref. '13') (Obsoleted by RFC
     8141)

  ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref.
     '14')

  ** Obsolete normative reference: RFC 3023 (ref. '15') (Obsoleted by RFC
     7303)

  -- Possible downref: Non-RFC (?) normative reference: ref. '16'

  -- Possible downref: Non-RFC (?) normative reference: ref. '17'

  ** Obsolete normative reference: RFC 2234 (ref. '18') (Obsoleted by RFC
     4234)


     Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	SIMPLE                                                      H. Khartabil
3	Internet-Draft                                               M. Lonnfors
4	Expires: April 23, 2004                                 J. Costa-Requena
5	                                                             E. Leppanen
6	                                                                   Nokia
7	                                                        October 24, 2003

9	       An Extensible Markup Language (XML) Based Format for Event
10	                         Notification Filtering
11	                draft-khartabil-simple-filter-format-01

13	Status of this Memo

15	   This document is an Internet-Draft and is in full conformance with
16	   all provisions of Section 10 of RFC2026.

18	   Internet-Drafts are working documents of the Internet Engineering
19	   Task Force (IETF), its areas, and its working groups. Note that other
20	   groups may also distribute working documents as Internet-Drafts.

22	   Internet-Drafts are draft documents valid for a maximum of six months
23	   and may be updated, replaced, or obsoleted by other documents at any
24	   time. It is inappropriate to use Internet-Drafts as reference
25	   material or to cite them other than as "work in progress."

27	   The list of current Internet-Drafts can be accessed at http://
28	   www.ietf.org/ietf/1id-abstracts.txt.

30	   The list of Internet-Draft Shadow Directories can be accessed at
31	   http://www.ietf.org/shadow.html.

33	   This Internet-Draft will expire on April 23, 2004.

35	Copyright Notice

37	   Copyright (C) The Internet Society (2003). All Rights Reserved.

39	Abstract

41	   The SIP event notification framework describes the usage of the
42	   Session Initiation Protocol (SIP) for subscriptions and notifications
43	   of changes to a state of a resource. The document does not describe a
44	   mechanism of how filtering of event notification information can be
45	   achieved.

47	   In order to enable this, a format is needed to enable the subscriber
48	   to choose when notifications are to be sent to it and what they are
49	   to contain. This document presents a solution in the form of an XML
50	   document format.

52	Table of Contents

54	   1.      Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
55	   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
56	   3.      Structure of XML-Encoded Filter Criteria . . . . . . . . .  3
57	   3.1     The <filter-set> Root Element  . . . . . . . . . . . . . .  4
58	   3.2     The <filter> Element . . . . . . . . . . . . . . . . . . .  4
59	   3.3     The <what> Element . . . . . . . . . . . . . . . . . . . .  5
60	   3.3.1   The <condition> Element  . . . . . . . . . . . . . . . . .  5
61	   3.3.1.1 The "base-element" Attribute . . . . . . . . . . . . . . .  6
62	   3.3.2   The <include> Element  . . . . . . . . . . . . . . . . . .  6
63	   3.3.2.1 The "type" Attribute . . . . . . . . . . . . . . . . . . .  7
64	   3.3.2.2 The "level" Attribute  . . . . . . . . . . . . . . . . . .  7
65	   3.3.3   The <exclude> Element  . . . . . . . . . . . . . . . . . .  8
66	   3.4     The <trigger> Element  . . . . . . . . . . . . . . . . . .  8
67	   3.4.1   The <changed> Element  . . . . . . . . . . . . . . . . . .  8
68	   3.4.1.1 The "changed-from" Attribute . . . . . . . . . . . . . . .  9
69	   3.4.1.2 The "changed-to" Attribute . . . . . . . . . . . . . . . .  9
70	   3.4.1.3 The "changed-by" Attribute . . . . . . . . . . . . . . . .  9
71	   3.4.1.4 Combination of Attributes  . . . . . . . . . . . . . . . .  9
72	   3.4.2   The <added> Element  . . . . . . . . . . . . . . . . . . .  9
73	   3.4.3   The <removed> Element  . . . . . . . . . . . . . . . . . . 10
74	   4.      Syntax for Referencing XML Items and Making Logical
75	           Expressions  . . . . . . . . . . . . . . . . . . . . . . . 10
76	   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 10
77	   6.      Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11
78	   6.1     Filter Criteria Using <what> Element . . . . . . . . . . . 11
79	   6.2     Filter Criteria Using <trigger> Element  . . . . . . . . . 12
80	   6.3     Filter Criteria Using <what> and <trigger> Elements  . . . 12
81	   6.4     Content Filter Using Namespaces  . . . . . . . . . . . . . 13
82	   6.5     Content Filter Using Only <Include> Elements . . . . . . . 13
83	   6.6     Two Content Filters as Filter Criteria . . . . . . . . . . 14
84	   7.      XML Schema for Filter Criteria . . . . . . . . . . . . . . 15
85	   8.      Security Requirements  . . . . . . . . . . . . . . . . . . 17
86	   9.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18
87	   10.     Changes from version 00  . . . . . . . . . . . . . . . . . 18
88	           References . . . . . . . . . . . . . . . . . . . . . . . . 18
89	           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 20
90	           Intellectual Property and Copyright Statements . . . . . . 21

92	1. Conventions

94	   In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
95	   'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
96	   and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1]
97	   and indicate requirement levels for compliant implementations.

99	2. Introduction

101	   Filtering is a mechanism for defining the preferred content to be
102	   delivered and for specifying the rules for when the content should be
103	   delivered. See requirements in [9] and [10].

105	   The filtering mechanism is expected to be particularly valuable to
106	   users of mobile wireless access devices. The characteristics of the
107	   devices typically include high latency, low bandwidth, low data
108	   processing capabilities, small display, and limited battery power.
109	   Such devices can benefit from the ability to filter the amount of
110	   information generated at the source of the event notification.

112	   The SIP event notification framework [6] describes the usage of the
113	   Session Initiation Protocol (SIP) for subscriptions and notifications
114	   of changes to a state of a resource. The document does not describe a
115	   mechanism of how filtering of event notification information can be
116	   achieved.

118	   The structure of the filter criteria is described using the XML
119	   Schema. The filter criteria is presented as an XML document. The XML
120	   document contains the user's preference when notifications are to be
121	   sent to it and what they are to contain. The scope of the "when" part
122	   is triggering.

124	   The triggering is defined as enabling a subscriber to specify
125	   triggering rules for notifications where the criteria are based on
126	   changes of the package specific state information, e.g., for the
127	   presence information document [5] the change in the value of the
128	   <status> element.

130	   The functionality of the filtering regarding the SIP event
131	   notifications is specified in [11].

133	3. Structure of XML-Encoded Filter Criteria

135	   The filter criteria is an XML document [16] that MUST be well-formed
136	   and MUST be valid. The filter criteria XML documents MUST have the
137	   XML declaration and it SHOULD contain an encoding declaration in the
138	   XML declaration, for example; "<?XML version='1.0'
139	   encoding='UTF-8'?>". This specification makes use of XML namespaces
140	   for identifying the XML schema of the filter criteria instance
141	   documents and document fragments.

143	   The namespace identifier for elements defined by this specification
144	   is a URN [13], using the namespace identifier 'ietf' defined by [14]
145	   and extended by [12]. This urn is:
146	   urn:ietf:params:xml:ns:simple-filter+xml.

148	   This namespace declaration indicates the namespace on which the
149	   filter criteria are based on.

151	3.1 The <filter-set> Root Element

153	   The root element of the filter criteria is <filter-set>.

155	   The <filter-set> element MUST contain the namespace definition
156	   mentioned above. With the optional "package" attribute it is possible
157	   to define the package to which the filter criteria is applied. This
158	   might be especially useful in cases where the XML document containing
159	   the filter criteria is separated from the events that makes use of it
160	   or from the protocol that usually carries it.

162	   The <filter-set> element MUST contain one or more <filter> elements.

164	3.2 The <filter> Element

166	   The <filter> element is used to specify the content of an individual
167	   filter.

169	   The <filter> MUST have an 'id' attribute. The value of the 'id'
170	   attribute MUST be unique within the <filter-set> element. The
171	   <filter> MAY have an 'uri' attribute. The value of the 'uri'
172	   attribute is the URI of the resource which information is requested
173	   for.

175	   The URI of the resource is useful in cases where the 'eventlist'
176	   extension [7] is used with a package and different filters are
177	   defined for one or more members of the list. The 'uri' attribute in
178	   the <filter> element identifies either the URI of the list (or nested
179	   sub-list) or the URI of an individual member within the list to whom
180	   that specific filter applies. If the <filter> does not contain the
181	   'uri' attribute, the filter applies to all the members in the list
182	   unless a member of the list has its own filter attributed by the
183	   'uri' attribute.

185	   The <filter> MAY have a 'remove' attribute which indicates together
186	   with the 'id' attribute the existing filter to be removed. The value
187	   of the 'remove' attribute is of the type "Boolean". The default value
188	   is 'false'.

190	   The <filter> element MAY contain a <what> element and MAY contain one
191	   or more <trigger> elements, but MUST contain either the <what>
192	   element or the <trigger> element.

194	3.3 The <what> Element

196	   The <what> element is used to specify the content to be delivered to
197	   the user. It does not specify the exact content but the rules that
198	   are used to construct that information.

200	   The <what> element MAY contain a <condition> element, one or more
201	   <include> elements and one or more <exclude> elements. However, the
202	   <what> element MUST contain at least one <include> element.

204	3.3.1 The <condition> Element

206	   The <condition> element is used to select "base elements" using
207	   values of XML elements or XML attributes related to the base
208	   elements. The base element is defined by a mandatory XML attribute
209	   ("base-element"). The value of the <condition> element consists of
210	   comparison and logical expressions that has a Boolean outcome. The
211	   syntax for the expressions is defined in Section 4 (see the
212	   definition of the "expression"). The base element is selected if the
213	   expression is positive.

215	   The following example selects the tuples that have a <basic> element
216	   of the value 'open':

218	   <condition base-element="//tuple">status/basic="open"</condition>.

220	   A couple of example expressions are listed below:

222	   o  Comparison expressions using XML elements:

224	      *  /status/basic="open"

226	      *  */basic="open"

228	   o  Comparison expressions using XML attributes:

230	      *  @duration-subscribed<500

232	      *  @event="rejected"

234	   o  Logical expressions using values of two XML elements:

236	      *  status/basic="open" and type="device".

238	3.3.1.1 The "base-element" Attribute

240	   The "base-element" attribute defines the base element selected by the
241	   expression. The "base-element" attribute is used to identify the
242	   element itself or an ancestor element of the XML element or attribute
243	   that used in the expression. The syntax of the value of the
244	   "base-element" is defined in Section 4 (see the definition of the
245	   "reference").

247	   Examples of values of the "base-element" attribute are listed as
248	   follows:

250	   o  //tuple

252	   o  /presence/tuple

254	   o  //*

256	   o  /*/tuple.

258	3.3.2 The <include> Element

260	   The <include> element is used to select the content to be delivered.
261	   The value of the <include> element depends on the "type" attribute.
262	   The value is allowed to be a reference to an XML element or
263	   attribute, a namespace or another value related to the "type"
264	   attribute. Another XML attribute in the <include> is "level". The
265	   optional "level" attribute is used to select elements related to the
266	   element identified in the body of the <include> element.

268	   Note that in addition to the content defined using the <include>
269	   elements also other mandatory XML items may become selected to make
270	   the resulting XML document valid.

272	   The following example selects descendants of the <status> element.
273	   Thus, it selects the <basic> element according to [2].

275	   <include type="xml-element" level="descendant">//tuple/status</
276	   include>.

278	   If both the <condition> and the <include> elements are defined in a
279	   content filter, the value of the <include> element relates to the
280	   base element in such a way that the value of the <include> element
281	   MUST be either the defined base element or one of the lower level
282	   ("child") elements of the base element.

284	3.3.2.1 The "type" Attribute

286	   The "type" attribute is used to describe the value of the <include>
287	   element. The following values are pre-defined: 'xml-element',
288	   'namespace' and 'token'. Other values of the "type" attribute may be
289	   defined later. The "type" attribute is optional, and, if omitted, the
290	   default value is 'xml-element'.

292	   The 'xml-element' is used when the <include> element contains a
293	   reference of an XML element or attribute. Section 4 defines the
294	   syntax for the reference (see the definitions of the "reference" for
295	   referencing the XML elements and "attr-reference" for referencing the
296	   XML attributes).

298	   Example references are listed as follows:

300	   o  Referencing XML elements giving the full hierarchical path: /
301	      presence/tuple/status/basic

303	   o  Referencing XML elements from any level by its name: //basic

305	   o  Referencing XML attributes of an XML element: //watcher/
306	      @duration-subscribed

308	   o  Referencing XML attributes of any element: //@expiration.

310	   The "namespace" value is used when the <include> element contains a
311	   value of a namespace. The value is the URI of the namespace.

313	   The "token" is used to define the content by a value referring to a
314	   certain pre-defined set of elements (e.g., elements which are
315	   semantically close to each other) supported by a entity intepreting
316	   the filter.

318	   Example: <include type="token">location</include>.

320	3.3.2.2 The "level" Attribute

322	   The "level" attribute is used to select the related elements of the
323	   element identified in the <include> element, along with the
324	   identified element itself. The following values are pre-defined:
325	   'self', 'ancestor' and 'descendant'. If the attribute is omitted the
326	   default value is 'self'.

328	   Note that only the 'self' value makes sense to the include
329	   definitions of the types 'namespace' and 'token'.

331	   The 'self' value indicates the selection of the given XML element.
332	   The 'ancestor' value indicates the selection of the parent elements
333	   of the given XML element. The 'descendant' value indicates the
334	   selection of the sub-tree ("child elements") of the given XML
335	   element. The Section 4 defines the syntax for referencing the XML
336	   element.

338	3.3.3 The <exclude> Element

340	   The <exclude> element is used to define exceptions to the set of XML
341	   elements and/or attributes selected by the <include> elements. Thus,
342	   those XML elements (including their lower level "child" elements)
343	   and/or attributes defined by the <exclude> element are not delivered.
344	   The <exclude> element has the optional "type" attribute (see the
345	   definition of the "type" in Section 3.3.2.1).

347	   The <exclude> element can be used only if one or more <include>
348	   element(s) have been included in the same content filter.

350	3.4 The <trigger> Element

352	   The <trigger> element is used to identify the package specific
353	   changes that a resource has to encounter before the content is
354	   delivered to the subscriber. It can appear more than once in a filter
355	   document. Multiple appearances of this element denotes the "OR"
356	   operation. This means that updates to a resource that satisfy any of
357	   the <trigger> elements criteria constitute the content to be
358	   delivered.

360	   The <trigger> element MAY contain the <changed> element, the <added>
361	   element or the <removed>, but MUST contain at least one of the three
362	   elements. Any combination of the 3 elements is possible. Multiple
363	   appearances of those element within a <trigger> element denotes the
364	   "AND" operation. This means that updates to a resource that satisfy
365	   ALL of the <changed>, <added> and <removed> elements' criteria within
366	   the <trigger> element constitute the content to be delivered.

368	3.4.1 The <changed> Element

370	   The <changed> element is used to identify the XML element or
371	   attribute, from the package specific XML document, that must change,
372	   compared to the previous XML document, in order to activate the
373	   trigger and cause the content to be delivered. The XML element or
374	   attribute is indicated using the syntax defined in Section 4 for the
375	   "reference" and "attr-reference". The indication MUST only point to
376	   one XML element or attribute.

378	   The <changed> element MAY contain the "changed-from" attribute,
379	   "changed-to" attribute, "changed-by" attribute, or any combination of
380	   the three.

382	3.4.1.1 The "changed-from" Attribute

384	   A trigger is active when the XML element or attribute identified with
385	   the <changed> element has changed from the value indicated by this
386	   attribute to a different value.

388	3.4.1.2 The "changed-to" Attribute

390	   A trigger is active when the XML element or attribute identified with
391	   the <changed> element has changed to the value indicated by this
392	   attribute from a different value.

394	3.4.1.3 The "changed-by" Attribute

396	   A trigger is active when the XML element or attribute identified with
397	   the <changed> element has changed by the value indicated by this
398	   attribute from a different value.

400	3.4.1.4 Combination of Attributes

402	   Any combination of the "changed-from", "changed-to", and "changed-by"
403	   attributes in the <changed> element is possible. For example, if the
404	   "changed-from" attribute was combined with the "changed-to" attribute
405	   it is interpreted as: the trigger is active when the XML element or
406	   attribute identified with the <changed> element has changed from the
407	   "changed-from" value to the "changed-to" value. Note that if the
408	   "changed-by" attribute is used in combination with the other
409	   attributes, the other attribute types MUST match the "changed-by"
410	   type of decimal.

412	3.4.2 The <added> Element

414	   The <added> element is used to trigger the content delivery when the
415	   XML element or attribute, identified in it, has been added to the new
416	   XML document in comparison to the previous XML document. It can be
417	   used, for example,  to learn of new services and/or capabilities
418	   subscribed to by the user, or services and/or capabilities that the
419	   user has now allowed the subscriber to see. The XML element or
420	   attribute is indicated using the syntax defined in Section 4 for the
421	   "reference" and "attr-reference".

423	   Note that if a filter includes both the content filter (<what>) part
424	   and the <added> element then the definitions of the <what> part
425	   SHOULD cover also the added elements, or otherwise the content is
426	   delivered without the items defined in the <added> element.

428	3.4.3 The <removed> Element

430	   The <removed> element is used to trigger the content to be delivered
431	   when the XML element or attribute, identified in it, has been removed
432	   from the new XML document in comparison to the previous XML document.
433	   The XML element or attribute is indicated using the syntax defined in
434	   Section 4 for the "reference" and "attr-reference".

436	4. Syntax for Referencing XML Items and Making Logical Expressions

438	   The ABNF [18] is used to describe the syntax for the references and
439	   expressions. The syntax is defined to be XPATH [17] compatible, but
440	   has only a restricted set of capabilities of the XPATH. More
441	   information about the meaning of the items of the syntax can be found
442	   in [17]. The "abbreviated syntax" of the "node test" is used in the
443	   references ("reference" and "attr-reference"). The expression in the
444	   syntax relates to the predicate, comparision and logical expressions
445	   of the XPATH. The square brackets of predicate expression are left
446	   out.

448	   expression = (elem-expr / attr-expr) 1*[oper (elem-expr / attr-expr)]
449	   elem-expr = (elem-path / ".") compar value
450	   elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]
451	   attr-expr = [elem-path "/"] attribute compar value

453	   reference = "/" 1*("/" / "/*" / ("/" element))
454	   attr-reference = reference attribute

456	   oper = "and" / "or"
457	   compar = "=" / "<" / ">"
458	   element = [ns] string
459	   attribute = "@" [ns] string
460	   ns = string ":"
461	   string = <any sequence of data supported by XML in names of XML element, and/or attribute or prefixes of namespaces>
462	   value = <any sequence of data supported by XML as a value of the XML element and/or attribute>

464	5. IANA Considerations

466	   A new content type "application/simple-filter+xml" is defined to
467	   represent an XML MIME for the filter criteria.

469	   This specification follows the guidelines of RFC3023 [15]

471	   OPEN ISSUE: IANA registration template must be added later.

473	6. Examples

475	   The XML Schema for the XML document examples is specified in the
476	   Section 7.

478	6.1 Filter Criteria Using <what> Element

480	   This example shows two ways for defining a content filter where the
481	   whole content and upper level elements of the tuples of the presence
482	   information are selected based on a condition defined by a logical
483	   expression. The condition is: select <class> elements that have a
484	   value "MMS", "SMS" or "IM".

486	   The <class> element is defined in [3] as extension to PIDF [2]. The
487	   first filter definition includes optional elements while the second
488	   filter definition shows only the minimum set of definitions.

490	   The first filter definition:

492	   <?xml version="1.0" encoding="UTF-8"?>
493	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
494	   		xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"
495	   		package="presence">
496	         <filter id="mess" uri="sip:presentity@domain.com">
497	   	      <what>
498	   	      		<condition base-element="//tuple" type="xml-element">rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"
499	   			</condition>
500	   			<include level="self" type="xml-element">//tuple</include>
501	   			<include level="descendant">//tuple</include>
502	   			<include level="ancestor">//tuple</include>
503	               </what>
504	   	   </filter>
505	   </filter-set>

507	   Another alternative definition is presented below. Note that one of
508	   the <include> elements is omitted which means that it is assumed that
509	   the data format (PIDF [2]) mandates, e.g., the upper level elements
510	   of the selected tuples to be delivered.

512	   <?xml version="1.0" encoding="UTF-8"?>
513	      <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
514	            <filter id="mess">
515	                <what>
516	   		  <condition base-element="//tuple">class="IM" or class="SMS" or class="MMS"</condition>
517	   		  <include>//tuple</include>
518	   		  <include level="descendant">//tuple</include>
519	                </what>
520	      	   </filter>
521	      </filter-set>

523	6.2 Filter Criteria Using <trigger> Element

525	   This filter criteria selects the content to be delivered to the
526	   subscriber when a certain PIDF [2] tuple changes its <basic> status
527	   from 'CLOSED' to 'OPEN'.

529	   <?xml version="1.0" encoding="UTF-8"?>
530	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
531	        <filter id="open_mean" uri="sip:presentity@domain.com">
532	           <trigger>
533	                    <changed changed-from="CLOSED" changed-to="OPEN">/presence/tuple/status/basic</changed>
534	           </trigger>
535	        </filter>
536	   </filter-set>

538	6.3 Filter Criteria Using <what> and <trigger> Elements

540	   This filter criteria selects watcher information notifications [8] to
541	   be sent when the pending subscription status has changed from
542	   "pending" to "terminated". In the notification, only the watchers
543	   that have a status of "terminated" and an event of "rejected" are
544	   included.

546	   <?xml version="1.0" encoding="UTF-8"?>
547	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
548	                       package="winfo">
549	         <filter id="filterX" uri="sip:presentity@domain.com">
550	            <what>
551	   	    	<condition base-element="//watcher">
552	   			@status="terminated" and @event="rejected"
553	       		</condition>
554	       		<include>//watcher</include>
555	       		<include level="ancestor">//watcher</include>
556	            </what>
557	            <trigger>
558	                 <changed changed-from="pending" changed-to="terminated">//watcher/@status</changed>
559	            </trigger>
560	         </filter>
561	   </filter-set>

563	6.4 Content Filter Using Namespaces

565	   This filter criteria selects XML elements belonging to certain
566	   namespaces.

568	   <?xml version="1.0" encoding="UTF-8"?>
569	   	<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
570	                          package="presence">
571	   	   <filter id="filter-PIDF" uri="sip:buddylist@domain.com">
572	               	<what>
573	       			<include type="namespace"> urn:ietf:params:xml:ns:cpim-pidf
574	       			</include>
575	   		</what>
576	               </filter>
577	   	</filter-set>

579	6.5 Content Filter Using Only <Include> Elements

581	   This filter criteria selects certain XML elements.

583	   <?xml version="1.0" encoding="UTF-8"?>
584	        <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
585	   				package="presence">
586	           <filter id="filter-abc">
587	             	<what>
588	       		   <include>//status</include>
589	       		   <include>//icon</include>
590	       		   <include>/presence/tuple/note</include>
591	       		   <include>//vcard</include>
592	       		</what>
593	           </filter>
594	        </filter-set>

596	6.6 Two Content Filters as Filter Criteria

598	   This filter criteria defines two content filters: the first one to be
599	   used for a list of "buddies" and the second one to get more
600	   information about one of the friends. The PIDF extension elements
601	   defined in [4] are filtered out.

603	   <?xml version="1.0" encoding="UTF-8"?>
604	      <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
605	   	xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"
606	   	xmlns:cip="urn:ietf:params:xml:ns:pidf:cipid">

608	            <filter id="8439" uri="sip:buddies@domain.com">
609	               	<what>
610	   			<condition base-element="//tuple">rpid:type="service" or rpid:type="device"
611	       			</condition>
612	       			<include>//contact</include>
613	       			<include>//status</include>
614	       			<include level="descendant">//status</include>
615	       			<include level="ancestor">//status</include>
616	   		</what>
617	            </filter>

619	            <filter id="999" uri="sip:friendX@domain.com">
620	               <what>
621	       			<condition base-element="//tuple">rpid:type="service" or rpid:type="device"
622	       			</condition>
623	       			<include>//tuple</include>
624	       			<include level="ancestor">//tuple</include>
625	       			<include level="descendant">//tuple</include>
626	       			<exclude type="namespace">urn:ietf:params:xml:ns:pidf:cipid</exclude>
627	   		</what>
628	            </filter>
629	      </filter-set>

631	7. XML Schema for Filter Criteria

633	   XML Schema Implementation (Normative)

635	   <?xml version="1.0" encoding="UTF-8"?>

637	   <xsd:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
638	   	xmlns="urn:ietf:params:xml:ns:simple-filter"
639	   	xmlns:xsd=http://www.w3.org/2001/XMLSchema/>
640	   	<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
641	     	schemaLocation="http://www.w3.org/2001/xml.xsd">   <!--lang -->

643	   	<xsd:annotation>
644	   	  <xsd:documentation xml:lang="en">
645	   	    XML Schema Definition for Filter Criteria.
646	   	  </xsd:documentation>
647	   	</xsd:annotation>

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

651	   	<xsd:complexType name="FilterSetType">
652	   	  <xsd:sequence>
653	   	    <xsd:element name="filter" type="FilterType"
654	   	                 minOccurs="1"    maxOccurs="unbounded"/>
655	   	  </xsd:sequence>
656	   	  <xsd:attribute name="package" type="xsd:string" use="optional"/>
657	   	</xsd:complexType>

659	   <!--  A filter corresponds to the URI indicated by its "uri" attribute. The URI defines the user or a list of users. -->

661	   	<xsd:complexType name="FilterType">
662	   	   <xsd:sequence>
663	   	       <xsd:element name="what" type="WhatType" minOccurs="0" maxOccurs="1"/>
664	   	       <xsd:element name="trigger" type="TriggerType" minOccurs="0" maxOccurs="unbounded"/>
665	   	   </xsd:sequence>
666	   	   <xsd:attribute name="id"  type="xsd:string" use="required"/>
667	   	   <xsd:attribute name="uri" type="xsd:anyURI" use="optional/>
668	   	   <xsd:attribute name="remove" type="xsd:boolean" default="false" use="optional"/>
669	   	</xsd:complexType>

671	      <xsd:complexType name="WhatType">
672	         <xsd:sequence>
673	             <xsd:element name="condition" type="CondType" minOccurs="0" maxOccurs="unbounded"/>
674	             <xsd:element name="include" type="InclType" minOccurs="1" maxOccurs="unbounded"/>
675	             <xsd:element name="exclude" type="ExclType" minOccurs="0" maxOccurs="unbounded"/>
676	   	   <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
677	         </xsd:sequence>
678	      </xsd:complexType>
679	      <xsd:complexType name="CondType">
680	        <xsd:simpleContent>
681	          <xsd:extension base="xsd:string">
682	   	       <xsd:attribute name="base-element" type="xsd:string" use="required"/>
683	   	       <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
684	          </xsd:extension>
685	         </xsd:simpleContent>
686	      </xsd:complexType>

688	      <xsd:complexType name="InclType">
689	         <xsd:simpleContent>
690	          <xsd:extension base="xsd:string">
691	   	      	<xsd:attribute name="level" type="LevelType" default="self" use="optional"/>
692	   	      	<xsd:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
693	   	       <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
694	          </xsd:extension>
695	         </xsd:simpleContent>
696	      </xsd:complexType>

698	      <xsd:complexType name="ExclType">
699	         <xsd:simpleContent>
700	          <xsd:extension base="xsd:string">
701	   	      	<xsd:attribute name="type" type="TypeType" default="xml-element" use="optional"/>
702	   	       <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
703	          </xsd:extension>
704	         </xsd:simpleContent>
705	      </xsd:complexType>

707	      <!--xsd:simpleType name="Base-elemType">
708	         <xsd:restriction base="xs:string">
709	   		<xsd:enumeration value="current">
710	   		<xsd:enumeration value="tuple">
711	   	 	<xsd:enumeration value="watcher">
712	         </xsd:restriction>
713	      </xsd:complexType -->

715	      <xsd:simpleType name="LevelType">
716	         <xsd:restriction base="xs:string">
717	   		<xsd:enumeration value="self">
718	   		<xsd:enumeration value="ancestor">
719	   	 	<xsd:enumeration value="descendant">
720	         </xsd:restriction>
721	      </xsd:complexType>

723	      <xsd:simpleType name="TypeType">
724	         <xsd:restriction base="xs:string">
725	   		<xsd:enumeration value="xml-element">
726	   		<xsd:enumeration value="namespace">
727	   		<xsd:enumeration value="token">
728	         </xsd:restriction>
729	      </xsd:complexType>

731	   	<xsd:complexType name="TriggerType">
732	   	   <xsd:sequence>
733	   	       <xsd:element name="changed" type="ChangedType" minOccurs="0" maxOccurs="unbounded"/>
734	   	       <xsd:element name="added" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
735	   	       <xsd:element name="removed" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
736	   		<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
737	   	   </xsd:sequence>
738	   	</xsd:complexType>

740	   	 <xs:complexType name="ChangedType">
741	   	    <xs:simpleContent>
742	   	        <xs:extension base="xds:string">
743	   	           <xs:attribute name="changed-from" type="xsd:anySimpleType" use="optional"/>
744	   	           <xs:attribute name="changed-to" type="xsd:anySimpleType" use="optional"/>
745	   	           <xs:attribute name="changed-by" type="xsd:decimal" use="optional"/>
746	   		   <xsd:anyAttribute namespace="##other" processContents="lax" use="optional"/>
747	   	        </xs:extension>
748	   	    </xs:simpleContent>
749	   	 </xs:complexType>

751	   </xsd:schema>

753	8. Security Requirements

755	   The filters in the body in a SIP message has a significant effect on
756	   the ways in which the request is handled at a server. As a result, it
757	   is especially important that messages containing this extension be
758	   authenticated and authorised.

760	   Processing of requests and looking up filter criteria requires a set
761	   of operations and searches, which can require some amount of
762	   computation. This enables a DoS attack whereby a user can send
763	   requests with substantial number of messages with large contents, in
764	   the hopes of overloading the server. To counter this, the server
765	   SHOULD only allow filters with no more than about 20 occurances of
766	   the <what>, <changed>, <added> and <removed> elements.

768	   Requests can reveal sensitive information about a UA's capabilities.
769	   If this information is sensitive, it SHOULD be encrypted using SIP S/
770	   MIME capabilities.

772	   All filtering related security measures discussed in [6] MUST be
773	   followed along with package specific security.

775	9. Acknowledgements

777	   The authors would like to thank Jonathan Rosenberg, Henning
778	   Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla and all
779	   the active SIMPLE mailing list contributors for their valuable input.

781	10. Changes from version 00

783	   o  Usage of exact XPATH support restricted (XPATH compatible syntax
784	      still used).

786	   o  New solution for the content filter. Examples and XML Schema
787	      updated accordingly.

789	   o  ABNF based syntax for data referencing and expressions added.

791	   o  More examples added.

793	   o  Terminology harmonized and references updated.

795	   o  Minor updates concerning the triggering part.

797	References

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

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

805	   [3]   Schulzrinne, H., "RPID -- Rich Presence Information Data
806	         Format",  draft-ietf-simple-rpid-00.txt (work in progress),
807	         July 2003.

809	   [4]   Schulzrinne, H., "CIPID: Contact Information in Presence
810	         Information Data Format",  draft-ietf-simple-cipid-00.txt (work
811	         in progress), August 2003.

813	   [5]   Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
814	         for Presence",  draft-ietf-simple-presence-10.txt, January
815	         2003.

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

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

824	   [8]   Rosenberg, J., "An Extensible Markup Language (XML) Based
825	         Format for Watcher Information",
826	         draft-ietf-simple-winfo-format-04.txt, January 2003.

828	   [9]   Khartabil, H., "Requirements for Presence Specific Event
829	         Notification Filtering",
830	         draft-ietf-simple-pres-filter-reqs-02.txt (work in progress),
831	         August 2003.

833	   [10]  Kiss, K., "Requirements for Filtering of Watcher Information",
834	         draft-ietf-simple-winfo-filter-reqs-00.txt (work in progress),
835	         April 2003.

837	   [11]  Khartabil, H., "Functional Description of Event Notification
838	         Filtering",  draft-khartabil-simple-filter-funct-00.txt (work
839	         in progress), May 2003.

841	   [12]  Mealling, M., "The IETF XML Registry",
842	         draft-mealling-iana-xmlns-registry-04.txt, June 2002.

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

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

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

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

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

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

860	Authors' Addresses

862	   Hisham Khartabil
863	   Nokia
864	   P.O. Box 321
865	   Helsinki
866	   Finland

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

871	   Mikko Lonnfors
872	   Nokia
873	   Itamerenkatu 00180
874	   Helsinki
875	   Finland

877	   Phone: + 358 50 4836402
878	   EMail: mikko.lonnfors@nokia.com

880	   Jose Costa-Requena
881	   Nokia
882	   P.O. Box 321
883	   FIN-00045 NOKIA GROUP
884	   FINLAND

886	   Phone: +358 71800 8000
887	   EMail: jose.costa-requena@nokia.com

889	   Eva Leppanen
890	   Nokia
891	   P.O BOX 785
892	   Tampere
893	   Finland

895	   Phone: +358 7180 77066
896	   EMail: eva-maria.leppanen@nokia.com

898	Intellectual Property Statement

900	   The IETF takes no position regarding the validity or scope of any
901	   intellectual property or other rights that might be claimed to
902	   pertain to the implementation or use of the technology described in
903	   this document or the extent to which any license under such rights
904	   might or might not be available; neither does it represent that it
905	   has made any effort to identify any such rights. Information on the
906	   IETF's procedures with respect to rights in standards-track and
907	   standards-related documentation can be found in BCP-11. Copies of
908	   claims of rights made available for publication and any assurances of
909	   licenses to be made available, or the result of an attempt made to
910	   obtain a general license or permission for the use of such
911	   proprietary rights by implementors or users of this specification can
912	   be obtained from the IETF Secretariat.

914	   The IETF invites any interested party to bring to its attention any
915	   copyrights, patents or patent applications, or other proprietary
916	   rights which may cover technology that may be required to practice
917	   this standard. Please address the information to the IETF Executive
918	   Director.

920	Full Copyright Statement

922	   Copyright (C) The Internet Society (2003). All Rights Reserved.

924	   This document and translations of it may be copied and furnished to
925	   others, and derivative works that comment on or otherwise explain it
926	   or assist in its implementation may be prepared, copied, published
927	   and distributed, in whole or in part, without restriction of any
928	   kind, provided that the above copyright notice and this paragraph are
929	   included on all such copies and derivative works. However, this
930	   document itself may not be modified in any way, such as by removing
931	   the copyright notice or references to the Internet Society or other
932	   Internet organizations, except as needed for the purpose of
933	   developing Internet standards in which case the procedures for
934	   copyrights defined in the Internet Standards process must be
935	   followed, or as required to translate it into languages other than
936	   English.

938	   The limited permissions granted above are perpetual and will not be
939	   revoked by the Internet Society or its successors or assignees.

941	   This document and the information contained herein is provided on an
942	   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
943	   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
944	   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
945	   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
946	   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

948	Acknowledgement

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