idnits 2.17.1 

draft-ietf-simple-filter-format-05.txt:

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

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1082.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1059.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1066.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1072.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        This document is an Internet-Draft and is subject to all provisions of
        Section 3 of RFC 3667.

        By submitting this Internet-Draft, each author represents that any
        applicable patent or other IPR claims of which he or she is aware
        have been or will be disclosed, and any of which he or she
        becomes aware will be disclosed, in accordance with Section 6 of
        BCP 79.


  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 :
  ----------------------------------------------------------------------------

     No issues found here.

  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 (March 15, 2005) is 6980 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)

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

  -- No information found for draft-simple-event-filter-funct - is the name
     correct?

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

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

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

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

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

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

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

  ** Obsolete normative reference: RFC 2633 (ref. '11') (Obsoleted by RFC
     3851)

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

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

  == Outdated reference: A later version (-10) exists of
     draft-ietf-simple-presence-rules-01


     Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--).

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

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


2	SIMPLE                                                      H. Khartabil
3	Internet-Draft                                                     Telio
4	Expires: September 16, 2005                                  E. Leppanen
5	                                                             M. Lonnfors
6	                                                        J. Costa-Requena
7	                                                                   Nokia
8	                                                          March 15, 2005

10	       An Extensible Markup Language (XML) Based Format for Event
11	                         Notification Filtering
12	                   draft-ietf-simple-filter-format-05

14	Status of this Memo

16	   This document is an Internet-Draft and is subject to all provisions
17	   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
18	   author represents that any applicable patent or other IPR claims of
19	   which he or she is aware have been or will be disclosed, and any of
20	   which he or she become aware will be disclosed, in accordance with
21	   RFC 3668.

23	   Internet-Drafts are working documents of the Internet Engineering
24	   Task Force (IETF), its areas, and its working groups.  Note that
25	   other groups may also distribute working documents as
26	   Internet-Drafts.

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

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

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

39	   This Internet-Draft will expire on September 16, 2005.

41	Copyright Notice

43	   Copyright (C) The Internet Society (2005).

45	Abstract

47	   The SIP event notification framework describes the usage of the
48	   Session Initiation Protocol (SIP) for subscriptions and notifications
49	   of changes to a state of a resource.  The document does not describe
50	   a mechanism of how filtering of event notification information can be
51	   achieved.  Filtering is a mechanism for defining the preferred
52	   notification information to be delivered and for specifying triggers
53	   that cause that information to be delivered.  In order to enable
54	   this, a format is needed to enable the subscriber to describe the
55	   state changes of a resource that cause notifications to be sent to it
56	   and what those notifications are to contain.  This document presents
57	   a format in the form of an XML document.

59	Table of Contents

61	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
62	   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
63	   3.  Structure of XML-Encoded simple-filter . . . . . . . . . . . .  5
64	     3.1   MIME Type for simple-filter Document . . . . . . . . . . .  5
65	     3.2   The <filter-set> Root Element  . . . . . . . . . . . . . .  5
66	     3.3   The <ns-bindings> Element  . . . . . . . . . . . . . . . .  5
67	     3.4   The <filter> Element . . . . . . . . . . . . . . . . . . .  6
68	     3.5   The <what> Element . . . . . . . . . . . . . . . . . . . .  7
69	       3.5.1   The <include> Element  . . . . . . . . . . . . . . . .  7
70	       3.5.2   The <exclude> Element  . . . . . . . . . . . . . . . .  8
71	       3.5.3   The 'type' Attribute . . . . . . . . . . . . . . . . .  8
72	     3.6   The <trigger> Element  . . . . . . . . . . . . . . . . . .  8
73	       3.6.1   The <changed> Element  . . . . . . . . . . . . . . . .  9
74	         3.6.1.1   The 'from' Attribute . . . . . . . . . . . . . . .  9
75	         3.6.1.2   The 'to' Attribute . . . . . . . . . . . . . . . .  9
76	         3.6.1.3   The 'by' Attribute . . . . . . . . . . . . . . . .  9
77	         3.6.1.4   Combination of Attributes  . . . . . . . . . . . . 10
78	       3.6.2   The <added> Element  . . . . . . . . . . . . . . . . . 10
79	       3.6.3   The <removed> Element  . . . . . . . . . . . . . . . . 10
80	   4.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 10
81	   5.  Syntax for Referencing XML Items and Making Logical
82	       Expressions  . . . . . . . . . . . . . . . . . . . . . . . . . 11
83	   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
84	     6.1   Filter Criteria Using <what> Element . . . . . . . . . . . 13
85	     6.2   Filter Criteria Using <trigger> Element  . . . . . . . . . 14
86	     6.3   Filter Criteria Using <what> and <trigger> Elements  . . . 14
87	     6.4   Content Filter Using Namespaces  . . . . . . . . . . . . . 15
88	     6.5   Content Filter Using Only <include> Elements . . . . . . . 16
89	     6.6   Two Content Filters as Filter Criteria . . . . . . . . . . 16
90	   7.  XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 17
91	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
92	   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
93	     9.1   application/simple-filter+xml MIME TYPE  . . . . . . . . . 20
94	     9.2   URN Sub-Namespace Registration for
95	           urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 21

97	     9.3   Schema Registration  . . . . . . . . . . . . . . . . . . . 21
98	   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
99	   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22
100	     11.1  Normative References . . . . . . . . . . . . . . . . . . . 22
101	     11.2  Informative References . . . . . . . . . . . . . . . . . . 23
102	       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
103	       Intellectual Property and Copyright Statements . . . . . . . . 25

105	1.  Introduction

107	   The SIP event notification framework [2] describes the usage of the
108	   Session Initiation Protocol (SIP) for subscriptions and notifications
109	   of changes to a state of a resource.  The document does not describe
110	   a  mechanism of how filtering of event notification information can
111	   be achieved.

113	   Filtering is a mechanism for defining the preferred notification
114	   information, referred to as content, to be delivered and for
115	   specifying the rules for when that information should be delivered.

117	   The filtering mechanism is expected to be particularly valuable and
118	   primarily applicable to users of mobile wireless access devices.  The
119	   characteristics of the devices typically include high latency, low
120	   bandwidth, low data processing capabilities, small display, and
121	   limited battery power.  Such devices can benefit from the ability to
122	   filter the amount of information generated at the source of the event
123	   notification.  However, implementers need to be aware of the
124	   computational burden on the source of the event notification.  This
125	   is discussed further in Section 8.

127	   The structure of the filter criteria is described using the XML
128	   Schema.  The filter criteria is presented as an XML document.  The
129	   XML document contains the user's preference when notifications are to
130	   be sent to it and what they are to contain.  The scope of the "when"
131	   part is triggering.

133	   The triggering is defined as enabling a subscriber to specify
134	   triggering rules for notifications where the criteria are based on
135	   changes of the event package [2] specific state information, e.g.,
136	   for the presence information document [15] the change in the value of
137	   the <status> element.

139	   The functionality of the filtering regarding the SIP event
140	   notifications is specified in [3].

142	2.  Conventions

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

149	   Throughout the document, the "resulting XML document" refers to the
150	   final XML document that carries state information to be delivered to
151	   the subscriber after the filters have been applied to it.

153	   "Content" refers to the XML document that appears in a notification
154	   reflecting the state of a resource.

156	3.  Structure of XML-Encoded simple-filter

158	   A simple-filter is an XML document [8] that MUST be well-formed and
159	   MUST be valid according to schemas, including extension schemas,
160	   available to the validater and applicable to the XML document.  The
161	   simple-filter documents MUST be based on XML 1.0 and MUST be encoded
162	   using UTF-8.

164	   The namespace identifier for elements defined by this specification
165	   is a URN [5], using the namespace identifier 'ietf' defined by [6]
166	   and extended by [4].  This urn is:
167	   urn:ietf:params:xml:ns:simple-filter.

169	   This namespace declaration indicates the namespace on which the
170	   filter criteria are based on.

172	3.1  MIME Type for simple-filter Document

174	   The MIME type for the simple-filter document is
175	   "application/simple-filter+xml".  Any transport protocol (SIP [12],
176	   for example) that is used to carry the filters that also carries
177	   payload type information MUST identify the payload as MIME type
178	   "simple-filter+xml" (for example: a Content-Type header field).

180	3.2  The <filter-set> Root Element

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

184	   The <filter-set> element contains the namespace definition mentioned
185	   above.  With the optional 'package' attribute, it is possible to
186	   define the package to which the filter criteria is applied.  This
187	   might be especially useful in cases where the XML document containing
188	   the filter criteria is separated from the events that make use of it
189	   or from the protocol that usually carries it.

191	   The <filter-set> element may contain one <ns-bindings> elements.

193	   The <filter-set> element contains one or more <filter> elements.

195	3.3  The <ns-bindings> Element

197	   The <ns-bindings> element is used to bind namespaces to local
198	   prefixes used in expressions that select elements or attributes using
199	   the syntax in Section 5.  Those prefixes apply to the <include>,
200	   <exclude>,  <changed>, <added> and <removed> elements.

202	   The <ns-bindings> element contains one or more <ns-binding> elements.
203	   Each <ns-binding> element has a 'prefix' attribute.  The value of the
204	   'prefix' attribute is a prefix used to qualify the elements pointed
205	   to by the expression.  The <ns-binding> element also has a 'urn'
206	   attribute that identifies the namespace that the prefix represents.

208	3.4  The <filter> Element

210	   The <filter> element is used to specify the content of an individual
211	   filter.

213	   The <filter> element has an 'id' attribute.  The value of the 'id'
214	   attribute MUST be unique within the <filter-set> element.  The
215	   <filter> MAY have an 'uri' attribute.  The value of the 'uri'
216	   attribute is the URI of the resource which the filter applies to.
217	   The <filter> MAY have an 'domain' attribute.  The value of the
218	   'domain' attribute is the domain of the resources that the filter
219	   applies to.  The 'uri' attribute and the 'domain' attribute MUST NOT
220	   appear together in a filter.

222	   The URI of the resource is useful in cases where the 'event list'
223	   extension [17] is used with a package.  Since a subscription to an
224	   event package may be addressed to an event list, the 'uri' attribute
225	   allows the subscriber to define a filter specific to an individual
226	   resource within that list.  That resource may be another list.  The
227	   'uri' attribute may, of course, carry the URI of the list itself.  If
228	   the <filter> does not contain the 'uri' attribute, the filter applies
229	   to the resource identified in the subscription request.

231	   The 'domain' attribute carries a domain.  In this case, the filter
232	   applies to resources who's URI has a domain part matching that
233	   domain.  This can be used when a subscription is for a resource that
234	   is an event list with many resources from differing domains.

236	   URI matching is done according to the matching rules defined for a
237	   particular scheme.  When matching domains, the user part of the URI
238	   is ignored for matching purposes.

240	   The <filter> MAY have a 'remove' attribute which indicates together
241	   with the 'id' attribute the existing filter to be removed.  The value
242	   of the 'remove' attribute is of the type "Boolean".  The default
243	   value is "false".

245	   The <filter> MAY have a 'enabled' attribute which indicates whether a
246	   filter is enabled or disabled.  The value of the 'enabled' attribute
247	   is of the type "Boolean".  The default value is "true".

249	   The <filter> element MAY contain a <what> element and MAY contain one
250	   or more <trigger> elements, but MUST contain either the <what>
251	   element or the <trigger> element when the filter is being enabled for
252	   the first time.  When a filter is disabled by setting the 'enabled'
253	   attribute to "false", the <what> and <trigger> elements MAY be
254	   omitted.  Similarily, when a filter is re-enabled by setting the
255	   'enabled' attribute to "true", the <what> and <trigger> elements MAY
256	   be omitted.

258	   Filter contents can be changed by changing the contents in the <what>
259	   and <trigger> elements and maintaining the value of the filter 'id'
260	   attribute.

262	3.5  The <what> Element

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

268	   The <what> element may contain one or more <include> elements and one
269	   or more <exclude> elements.  When more than one <include> element has
270	   been defined, the results are additive.  I.e.  each <include> element
271	   contents adds an element or attribute to the resulting XML document.
272	   When more than one <exclude> element has been defined, each <exclude>
273	   element value depletes the contents of the resulting XML document.

275	3.5.1  The <include> Element

277	   The <include> element is used to select the content to be delivered.
278	   Its value can identify an XML element, an attribute or a namespace of
279	   XML document to be filtered.  This is indicated using the 'type'
280	   attribute.

282	   Note that the resulting XML document MUST be valid.  Therefore, in
283	   addition to including the elements identified with the <include>
284	   element value, all other mandatory XML elements and/or attributes
285	   must be incorporated in the resulting XML document in order to make
286	   it valid.  This, in practice, means that a subscriber defining a
287	   filter only needs to <include> optional elements and/or attributes,
288	   but may <include> mandatory elements and/or attributes as well.
289	   There are also cases where a filter selects an attribute that belongs
290	   to an optional element.  In this case, the optional element needs to
291	   appear in the resulting XML document.

293	   The syntax defined in Section 5 (see the definition of "selection".)
294	   MUST be used.  The following example selects the <basic> element
295	   defined in the PIDF [13].  This results in the selection of the
296	   <basic> element as well as all the ancestors.  I.e.  <status> and
297	   <tuple>.

299	   <include type="xpath">/presence/tuple/status/basic</include>.

301	3.5.2  The <exclude> Element

303	   The <exclude> element is used to define exceptions to the set of XML
304	   elements and/or attributes selected by the <include> elements.  Thus,
305	   those XML elements (including their lower level "child" elements)
306	   and/or attributes defined by the <exclude> element are not delivered.
307	   This is most useful when an <include> element identifies a namespace.

309	   The <exclude> element has the optional 'type' attribute (see the
310	   definition of the 'type' in Section 3.5.3).

312	   Note that the resulting XML document MUST be valid.  Therefore, if
313	   the step in applying the <exclude> element value to an XML document
314	   results in an invalid document according to the schema, that step
315	   MUST be reveresed resulting in the elements and/or attributes being
316	   re-introduced into the resulting XML document, with their previous
317	   values, in order to make it valid.  This, in practice, means that a
318	   subscriber defining a filter only needs to <exclude> optional
319	   elements and/or attributes, but SHOULD NOT <exclude> mandatory
320	   elements and/or attributes.

322	   The syntax MUST follow Section 5.

324	3.5.3  The 'type' Attribute

326	   The 'type' attribute is used to describe the value of the <include>
327	   and <exclude> elements.  The following values are pre-defined:
328	   "xpath" and "namespace".  The 'type' attribute is optional, and, if
329	   omitted, the default value is "xpath".

331	   The "xpath" value is used when the <include> or <exclude> element
332	   contains a value following the syntax in Section 5 that selects an
333	   element or an attribute.

335	   The "namespace" value is used when the <include> or <exclude> element
336	   contains a value of a namespace.  The value is the URI of the
337	   namespace.  The resulting XML document is comprised of the elements
338	   defined within the namespace.

340	3.6  The <trigger> Element

342	   The <trigger> element is used to identify the package specific
343	   changes that a resource has to encounter before the content is
344	   delivered to the subscriber.  It can appear more than once in a
345	   <filter> element.  Multiple appearances of this element denotes the
346	   "OR" operation.  This means that updates to a resource that satisfy
347	   any of the <trigger> elements criteria constitute the content to be
348	   delivered.

350	   The <trigger> element MAY contain the <changed> element, the <added>
351	   element or the <removed>, but MUST contain at least one of the three
352	   elements.  Any combination of the 3 elements is possible.  Multiple
353	   appearances of those elements within a <trigger> element denotes the
354	   "AND" operation.  This means that updates to a resource that satisfy
355	   ALL of the <changed>, <added> and <removed> elements' criteria within
356	   the <trigger> element constitute the content to be delivered.

358	3.6.1  The <changed> Element

360	   The <changed> element is used to identify the XML element or
361	   attribute, from the package specific XML document, whose value MUST
362	   change, compared to the "previous XML document", in order to activate
363	   the trigger and cause the content to be delivered.  Previous XML
364	   document in this context refers to the last XML document that was
365	   selected for delivery to that specific subscription before any filter
366	   was applied to it.  The XML element or attribute MUST be expressed
367	   using the syntax defined in Section 5 for the "reference" ABNF.

369	   The <changed> element MAY contain the 'from' attribute, 'to'
370	   attribute, 'by' attribute, or any combination of the three.  The
371	   absence of all those attributes means a change of any sort to the
372	   value of the element or attribute activates the trigger.  An update
373	   to the element or attribute value with an identical value is not a
374	   change.

376	   Comparison of a change is done the element or attribute's lexical
377	   rules.

379	3.6.1.1  The 'from' Attribute

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

385	3.6.1.2  The 'to' Attribute

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

391	3.6.1.3  The 'by' Attribute

393	   A trigger is active when the XML element or attribute identified with
394	   the <changed> element has changed by at least the amount indicated by
395	   this attribute from a different value.  I.e.  The 'by' attribute
396	   applies only to numerical values and indicates a delta with respect
397	   the current value that an attribute or element (identified in the
398	   <changed> element) needs to change before it is selected.  For
399	   example: if the 'by' attribute is set to 2, and the current value of
400	   the element/attribute is 6, the element/attribute is selected when it
401	   reaches (or exceeds) the value 8 or when it decreases to 4 or lower
402	   value.

404	3.6.1.4  Combination of Attributes

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

415	3.6.2  The <added> Element

417	   The <added> element triggers content delivery when the XML element it
418	   identifies has been added to the document being filtered (that is,
419	   this instance of that element appears in the current document, but
420	   not the previous document).  It can be used, for example,  to learn
421	   of new services and/or capabilities subscribed to by the user, or
422	   services and/or capabilities that the user has now allowed the
423	   subscriber to see.  The XML element or attribute MUST be expressed
424	   using the syntax defined in Section 5 for the "reference" ABNF.

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

431	3.6.3  The <removed> Element

433	   The <removed> element triggers content delivery when the XML element
434	   it identifies has been removed from the document being filtered (that
435	   is, this instance of that element appeared in the previous document,
436	   but not the this document).  The XML element or attribute MUST be
437	   expressed using the syntax defined in Section 5 for the "reference"
438	   ABNF.

440	4.  XML Schema Extensibility

442	   The filter-set document is meant to be extended.  An extension takes
443	   place by defining a new set of elements in a new namespace, governed
444	   by a new schema.  Every extension MUST have an appropriate XML
445	   namespace assigned to it.  The XML namespace of the extension MUST be
446	   different from the namespaces defined in this specification.  The
447	   extension MUST NOT change the syntax or semantics of the schemas
448	   defined in this document.  All XML tags and attributes that are part
449	   of the extension MUST be appropriately qualified so as to place them
450	   within that namespace and MUST be designed such that receivers can
451	   safely ignore such extensions.

453	   This specification defines explict places where new elements or
454	   attributes from an extension can be placed.  These are explicitly
455	   indicated in the schemas by the <any> and <anyAttribute> elements.
456	   Extensions to this specification MUST specify where their elements
457	   can be placed within the document.

459	   As a result, a document that contains extensions will require
460	   multiple schemas in order to determine its validity - a schema
461	   defined in this document, along with those defined by extensions
462	   present in the document.  Because extensions occur by adding new
463	   elements and attributes governed by new schemas, the schemas defined
464	   in this document are fixed and would only be changed by a revision to
465	   this specification.  Such a revision, should it take place, would
466	   endeavor to allow documents compliant to the previous schema to
467	   remain compliant to the new one.  As a result, the schemas defined
468	   here don't provide explicit schema versions, as this is not expected
469	   to be needed.

471	5.  Syntax for Referencing XML Items and Making Logical Expressions

473	   The ABNF [10] is used to describe the syntax for the expressions.
474	   The syntax is defined to be XPATH [9] compatible, but has only a
475	   restricted set of capabilities of the XPATH.  More information about
476	   the meaning of the items of the syntax can be found in [9].  The
477	   "abbreviated syntax" of the "node test" is used in the references
478	   ("reference").  The expression in the syntax relates to the
479	   predicate, comparison and logical expressions of the XPATH.  If an
480	   XPATH expression evaluates to more than one element at a certain
481	   step, the filter applies to all the elements that are evaluated.
482	   I.e.  If a filter including a element evaluates to 2 elements, both
483	   elements are included as a result.

485	   selection = reference [expression]
486	   expression = "[" (elem-expr / attr-expr)
487	                         1*[oper (elem-expr / attr-expr)] "]"
488	   elem-expr = (elem-path / "." / "..") compar value
489	   elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]
490	   attr-expr = [elem-path "/"] attribute compar value

492	   reference = elem-reference / attr-reference
493	   elem-reference =  "/" 1*("/" / "/*" / ("/" element))
494	   attr-reference = reference attribute

496	   oper = "and" / "or"
497	   compar = "=" / "<" / ">"
498	   element = [ns] string
499	   attribute = "@" [ns] string
500	   ns = string ":"
501	   string = <any sequence of data supported by XML in names of XML
502	   element, and/or attribute or prefixes of namespaces>
503	   value = <any sequence of data supported by XML as a value of the
504	   XML element and/or attribute>

506	   When identifying XML elements or attributes, the value may consist of
507	   two parts: the XML element/attribute selector and the condition
508	   (comparison and logical expressions).  The XML element selector
509	   appears first followed by the condition part in square brackets.  In
510	   the XML element selector part the XML elements may be referenced by
511	   giving the full hierarchical path as: "/presence/tuple/status/basic",
512	   or by denoting the selection to cover any hierarchical level by its
513	   name as: "//tuple/status/basic" or using the wildcard "*" denoting
514	   any value in a certain level as "/*/watcher".

516	   Example references are listed as follows:

518	   o  Selecting an element by using an XML element as a condition:

520	      *  //*[status/basic="open"]

522	      *  /presence/tuple[*/basic="open"]

524	   o  Selecting an element by using XML attributes as a condition :

526	      *  //watcher[@duration-subscribed<500]

528	      *  /*/watcher[@event="rejected"]

530	   o  Selecting an element by using two XML elements as a condition :

532	      *  //tuple[status/basic="open" and type="device"]

534	   o  Selecting an attribute :

536	      *  //watcher/@duration-subscribed

538	   In some cases, due to the design of the XML schema, the XPATH-like
539	   expression results in identifying more than one element with the same
540	   name (the XPATH expression may not have uniquely identified an
541	   element at every step).  In those cases, all elements identified are
542	   selected.

544	   When evaluating XPath location steps, namespace expansion follows
545	   XPath 1.0 [9] semantics, i.e.  if the QName does not have a prefix
546	   then the namespace URI in the expanded name is null.  With
547	   non-default namespaces, expansion is done according to the given
548	   <ns-bindings> definitions.  When there's a default namespace used in
549	   the document, <ns-binding> element SHOULD be used to define an equal
550	   URI with some prefix in order to have a valid XPath evaluation in
551	   location steps.

553	6.  Examples

555	   The XML Schema for the XML document examples is specified in the
556	   Section 7.

558	6.1  Filter Criteria Using <what> Element

560	   A user wishes to get to know his friend's availability and
561	   willingness for messaging (SMS, IM and MMS) in order to know whether
562	   the friend is able to receive a message, the address to contact and
563	   the type of the message to be used.

565	   This example shows how to define a content filter.  The <basic>
566	   element as well as all parent elements are selected based on a
567	   condition defined by a logical expression.  The condition is: <class>
568	   elements that have a value "MMS", "SMS" or "IM".

570	   The <class> element is defined in [14] as an extension to PIDF [13].

572	   <?xml version="1.0" encoding="UTF-8"?>
573	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
574	     <ns-bindings>
575	       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
576	       <ns-binding prefix="rpid"
577	                          urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
578	     </ns-bindings>
579	     <filter id="123" uri="sip:presentity@example.com">
580	       <what>
581	         <include type="xpath">
582	           /pidf:presence/pidf:tuple[rpid:class="IM" or rpid:class="SMS"
583	           or rpid:class="MMS"]/pidf:status/pidf:basic
584	         </include>
585	       </what>
586	     </filter>
587	   </filter-set>

589	6.2  Filter Criteria Using <trigger> Element

591	   A user requires to get informed when his colleague becomes available
592	   by some communication mean(s).  The user gets the full presence state
593	   of the colleague when a certain PIDF [13] tuple <basic> status
594	   changes from 'CLOSED' to 'OPEN'.

596	   <?xml version="1.0" encoding="UTF-8"?>
597	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
598	     <ns-bindings>
599	       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
600	     </ns-bindings>
601	     <filter id="123" uri="sip:presentity@example.com">
602	       <trigger>
603	         <changed from="CLOSED" to="OPEN">
604	           /pidf:presence/pidf:tuple/pidf:status/pidf:basic
605	         </changed>
606	   </trigger>
607	   </filter>
608	   </filter-set>

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

612	   A user wishes to get information about pending and waiting
613	   subscriptions in order to be able to authorise watchers to see his
614	   presence information.

616	   The filter selects watcher information notifications [16] to be sent
617	   when a subscription status has changed to "pending" or "waiting".  In
618	   the notification, only the watchers that have a status of "pending"
619	   or "waiting" are included.

621	   <?xml version="1.0" encoding="UTF-8"?>
622	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
623	     <ns-bindings>
624	       <ns-binding prefix="wi"
625	                          urn="urn:ietf:params:xml:ns:watcherinfo"/>
626	     </ns-bindings>
627	     <filter id="123" uri="sip:presentity@example.com">
628	       <what>
629	         <include>
630	           /wi:watcherinfo/wi:watcher-list/wi:watcher[@status="pending"
631	           or @status="waiting"]
632	         </include>
633	       </what>
634	       <trigger>
635	         <changed to="pending">
636	           /wi:watcherinfo/wi:watcher-list/wi:watcher/@status
637	         </changed>
638	       </trigger>
639	       <trigger>
640	         <changed to="waiting">
641	           /wi:watcherinfo/wi:watcher-list/wi:watcher/@status
642	         </changed>
643	       </trigger>
644	     </filter>
645	   </filter-set>

647	6.4  Content Filter Using Namespaces

649	   A user turns her terminal on and the terminal automatically fetches
650	   general presence status and information about communication means
651	   from a certain pre-defined set of her buddies.

653	   The filter is defined to select XML elements belonging to the pidf
654	   namespace.

656	   <?xml version="1.0" encoding="UTF-8"?>
657	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
658	     <filter id="123" uri="sip:buddylist@example.com">
659	       <what>
660	         <include type="namespace">
661	           urn:ietf:params:xml:ns:pidf
662	         </include>
663	       </what>
664	     </filter>

666	   </filter-set>

668	6.5  Content Filter Using Only <include> Elements

670	   A user wants to know if a group of his friends are available for
671	   gaming.  He orders notifications about the current status and future
672	   changes of the game specific presence information.

674	   This filter is defined to select the game specific tuple to be
675	   delivered.

677	   <?xml version="1.0" encoding="UTF-8"?>
678	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" >
679	     <ns-bindings>
680	       <ns-binding prefix="game-ext"
681	                          urn="urn:ietf:params:xml:ns:game-ext"/>
682	     </ns-bindings>
683	     <filter id="123">
684	       <what>
685	         <include>
686	           /pidf:presence/pidf:tuple/
687	           pidf:status[game-ext:label="game-X"]
688	         </include>
689	       </what>
690	     </filter>
691	   </filter-set>

693	6.6  Two Content Filters as Filter Criteria

695	   The user is interested in getting up-to-date information about the
696	   communication means and contact addresses of his friends.  The user
697	   wants to get also more information (e.g.  location) about one of the
698	   friends in the list named Bob.  The PIDF element <note> is filtered
699	   out, i.e.  excluded.  The list was predefined as buddies@example.com.

701	   <?xml version="1.0" encoding="UTF-8"?>
702	   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
703	     <ns-bindings>
704	       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
705	       <ns-binding prefix="rpid"
706	                          urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
707	     </ns-bindings>
708	     <filter id="8439" uri="sip:buddies@example.com">
709	       <what>
710	         <include>
711	           /pidf:presence/pidf:tuple[rpid:class="service"]/pidf:status/
712	           pidf:basic
713	         </include>
714	       </what>
715	       </filter>
716	     <filter id="999" uri="sip:bob@example.com">
717	       <what>
718	         <include type="namespace">
719	           urn:ietf:params:xml:ns:pidf
720	         </include>
721	         <exclude>
722	           /pidf:presence/pidf:tuple/pidf:note
723	         </exclude>
724	       </what>
725	     </filter>
726	   </filter-set>

728	7.  XML Schema for Filter Criteria

730	   XML Schema Implementation (Normative)

732	   <?xml version="1.0" encoding="UTF-8"?>
733	   <xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
734	          xmlns="urn:ietf:params:xml:ns:simple-filter"
735	          xmlns:xs="http://www.w3.org/2001/XMLSchema"
736	          elementFormDefault="qualified">

738	     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
739	                      schemaLocation="http://www.w3.org/2001/xml.xsd"/>

741	     <xs:annotation>
742	       <xs:documentation xml:lang="en">
743	         XML Schema Definition for Filter Criteria.
744	       </xs:documentation>
745	     </xs:annotation>

747	     <xs:element name="filter-set" type="FilterSetType"/>
748	     <xs:complexType name="FilterSetType">
749	       <xs:sequence>
750	         <xs:element name="ns-bindings" type="NSBindings"
751	                             minOccurs="0" maxOccurs="1"/>
752	         <xs:element name="filter" type="FilterType"
753	                             minOccurs="1"    maxOccurs="unbounded"/>
754	         </xs:sequence>
755	       <xs:attribute name="package" type="xs:string" use="optional"/>
756	     </xs:complexType>

758	     <xs:complexType name="NSBindings">
759	       <xs:sequence>
760	         <xs:element name="ns-binding" type="NSBinding"
761	                             minOccurs="1" maxOccurs="unbounded"/>
762	       </xs:sequence>
763	     </xs:complexType>

765	     <xs:complexType name="NSBinding">
766	       <xs:attribute name="prefix" type="xs:string" use="required"/>
767	       <xs:attribute name="urn" type="xs:anyURI" use="required"/>
768	     </xs:complexType>

770	     <xs:complexType name="FilterType">
771	       <xs:sequence>
772	         <xs:element name="what" type="WhatType"
773	                             minOccurs="0" maxOccurs="1"/>
774	         <xs:element name="trigger" type="TriggerType"
775	                             minOccurs="0" maxOccurs="unbounded"/>
776	         <xs:any namespace="##other" processContents="lax"
777	                       minOccurs="0" maxOccurs="unbounded"/>
778	       </xs:sequence>
779	       <xs:attribute name="id"  type="xs:string" use="required"/>
780	       <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
781	       <xs:attribute name="domain" type="xs:string" use="optional"/>
782	       <xs:attribute name="remove" type="xs:boolean" use="optional"
783	                            default="false"/>
784	       <xs:attribute name="enabled" type="xs:boolean" use="optional"
785	                            default="true"/>
786	       <xs:anyAttribute namespace="##other" processContents="lax"/>
787	     </xs:complexType>

789	     <xs:complexType name="WhatType">
790	       <xs:sequence>
791	         <xs:element name="include" type="InclType"
792	                             minOccurs="0" maxOccurs="unbounded"/>
793	         <xs:element name="exclude" type="ExclType"
794	                             minOccurs="0" maxOccurs="unbounded"/>
795	         <xs:any namespace="##other" processContents="lax"
796	                       minOccurs="0" maxOccurs="unbounded"/>
797	       </xs:sequence>
798	     </xs:complexType>

800	     <xs:complexType name="InclType">
801	       <xs:simpleContent>
802	         <xs:extension base="xs:string">
803	           <xs:attribute name="type" type="TypeType"
804	                                default="xpath" use="optional"/>
805	           <xs:anyAttribute namespace="##other" processContents="lax"/>
806	         </xs:extension>
807	       </xs:simpleContent>
808	     </xs:complexType>

810	     <xs:complexType name="ExclType">
811	       <xs:simpleContent>
812	         <xs:extension base="xs:string">
813	           <xs:attribute name="type" type="TypeType"
814	                                default="xpath" use="optional"/>
815	           <xs:anyAttribute namespace="##other" processContents="lax"/>
816	         </xs:extension>
817	       </xs:simpleContent>
818	   </xs:complexType>

820	     <xs:simpleType name="TypeType">
821	       <xs:restriction base="xs:string">
822	         <xs:enumeration value="xpath"/>
823	         <xs:enumeration value="namespace"/>
824	       </xs:restriction>
825	     </xs:simpleType>

827	     <xs:complexType name="TriggerType">
828	       <xs:sequence>
829	       <xs:element name="changed" type="ChangedType"
830	                           minOccurs="0" maxOccurs="unbounded"/>
831	       <xs:element name="added" type="xs:string"
832	                           minOccurs="0" maxOccurs="unbounded"/>
833	       <xs:element name="removed" type="xs:string"
834	                           minOccurs="0" maxOccurs="unbounded"/>
835	       <xs:any namespace="##other" processContents="lax"
836	                          minOccurs="0" maxOccurs="unbounded"/>
837	       </xs:sequence>
838	     </xs:complexType>

840	     <xs:complexType name="ChangedType">
841	       <xs:simpleContent>
842	         <xs:extension base="xs:string">
843	           <xs:attribute name="from" type="xs:anySimpleType"
844	                                use="optional"/>
845	           <xs:attribute name="to" type="xs:anySimpleType"
846	                                use="optional"/>
847	           <xs:attribute name="by" type="xs:decimal"
848	                                use="optional"/>
849	           <xs:anyAttribute namespace="##other" processContents="lax"/>
850	         </xs:extension>
851	       </xs:simpleContent>
852	     </xs:complexType>

854	   </xs:schema>

856	8.  Security Considerations

858	   The filters in the body in a SIP message has a significant effect on
859	   the ways in which the request is handled at a server.  As a result,
860	   it is especially important that messages containing this extension be
861	   authenticated and authorised.  Authentication can be achieved using
862	   the Digest Authentication mechanism described in [12].  The
863	   authorisation decision is made based on the permissions that the
864	   resource (notifier) has given to the watcher.  An example of such
865	   auhorisation policy can be found in [18].

867	   Requests can reveal sensitive information about a UA's capabilities.
868	   If this information is sensitive, it SHOULD be encrypted using SIP
869	   S/MIME capabilities [11].

871	   All filtering related security measures discussed in [2] MUST be
872	   followed along with package specific security.

874	9.  IANA Considerations

876	   This document registers a new MIME type
877	   "application/simple-filter+xml", and registers a new XML namespace.

879	   This specification follows the guidelines of RFC3023 [7].

881	9.1  application/simple-filter+xml MIME TYPE

883	   MIME media type: application

885	   MIME subtype name: simple-filter+xml

887	   Mandatory parameters: none

889	   Optional parameters: Same as charset parameter application/xml as
890	   specified in RFC 3023 [7].

892	   Encoding considerations: Same as encoding considerations of
893	   application/xml as specified in RFC 3023 [7].

895	   Security considerations: See section 10 of RFC 3023 [7] and section
896	   Section 8 of this document.

898	   Interoperability considerations: none.

900	   Published specification: This document.

902	   Applications which use this media type: This document type has been
903	   used to support SIP based Event notification framework and its
904	   packages.

906	   Additional information:

908	   Magic number: None

910	   File extension: .cl or .xml

912	   Macintosh file type code: "TEXT"

914	   Personal and email address for further information: Hisham Khartabil
915	   (hisham.khartabil@telio.no)

917	   Intended Usage: COMMON

919	   Author/change controller: The IETF

921	9.2  URN Sub-Namespace Registration for
922	    urn:ietf:params:xml:ns:simple-filter

924	   This section registers a new XML namespace, as per guidelines in the
925	   IETF XML Registry [4].

927	   URI: The URI for this namespace is
928	   urn:ietf:params:xml:ns:simple-filter.

930	   Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
931	   (hisham.khartabil@telio.no)

933	9.3  Schema Registration

935	   This section registers a new XML schema per the procedures in [4].

937	   URI: urn:ietf:params:xml:ns:simple-filter

939	   Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
940	   (hisham.khartabil@telio.no).

942	   The XML for this schema can be found as the sole content of
943	   Section 7.

945	10.  Acknowledgements

947	   The authors would like to thank Jonathan Rosenberg, Henning
948	   Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla,
949	   Miguel-Angel Garcia Martin, Mary Barnes, Paul Kyzivat, Robert Sparks
950	   and Elwyn Davies for their valuable input and comments.

952	11.  References

954	11.1  Normative References

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

959	   [2]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
960	         Notification", RFC 3265, June 2002.

962	   [3]   Khartabil, H., "Functional Description of Event Notification
963	         Filtering",  draft-simple-event-filter-funct-05.txt, February
964	         2005.

966	   [4]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

968	   [5]   Moats, R., "The URN Syntax", RFC 2141, May 1997.

970	   [6]   Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
971	         August 1999.

973	   [7]   Murata, M., "XML Media Types", RFC 3023, March 1997.

975	   [8]   Bray, T., "Exensible Markup Language (XML) 1.0 (Second
976	         Edition)",  W3C CR CR-xml11-20011006, October 2000.

978	   [9]   Clark, J., "XML Path Language (XPath) Version 1.0",  W3C REC
979	         REC-xpath-19991116, November 1999.

981	   [10]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
982	         RFC 2234, November 1997.

984	   [11]  Ramsdell, B., "S/MIME Version 3 Message Specification",
985	         RFC 2633, June 1999.

987	11.2  Informative References

989	   [12]  Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
990	         A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
991	         "SIP: Session Initiation Protocol", RFC 3261, June 2002.

993	   [13]  Sugano, H., "Presence Information Data Format", RFC 3863,
994	         Auguest 2004.

996	   [14]  Schulzrinne, H., "RPID -- Rich Presence Information Data
997	         Format",  draft-ietf-simple-rpid-00.txt (work in progress), May
998	         2004.

1000	   [15]  Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
1001	         for Presence", RFC 3856, July 2004.

1003	   [16]  Rosenberg, J., "An Extensible Markup Language (XML) Based
1004	         Format for Watcher Information", RFC 3858, July 2004.

1006	   [17]  Roach, A., "A Session Initiation Protocol (SIP) Event
1007	         Notification Extension for Resource Lists",
1008	          draft-ietf-simple-event-list-04.txt, June 2003.

1010	   [18]  Rosenberg, J., "Presence Authorization Rules",
1011	          draft-ietf-simple-presence-rules-01, April 2005.

1013	Authors' Addresses

1015	   Hisham Khartabil
1016	   Telio
1017	   P.O. Box 1203 Vika
1018	   Oslo
1019	   Norway

1021	   Phone: +47 2167 3544
1022	   Email: hisham.khartabil@telio.no

1024	   Eva Leppanen
1025	   Nokia
1026	   P.O BOX 785
1027	   Tampere
1028	   Finland

1030	   Phone: +358 7180 77066
1031	   Email: eva-maria.leppanen@nokia.com
1032	   Mikko Lonnfors
1033	   Nokia
1034	   Itamerenkatu 00180
1035	   Helsinki
1036	   Finland

1038	   Phone: + 358 50 4836402
1039	   Email: mikko.lonnfors@nokia.com

1041	   Jose Costa-Requena
1042	   Nokia
1043	   P.O. Box 321
1044	   FIN-00045 NOKIA GROUP
1045	   FINLAND

1047	   Phone: +358 71800 8000
1048	   Email: jose.costa-requena@nokia.com

1050	Intellectual Property Statement

1052	   The IETF takes no position regarding the validity or scope of any
1053	   Intellectual Property Rights or other rights that might be claimed to
1054	   pertain to the implementation or use of the technology described in
1055	   this document or the extent to which any license under such rights
1056	   might or might not be available; nor does it represent that it has
1057	   made any independent effort to identify any such rights.  Information
1058	   on the procedures with respect to rights in RFC documents can be
1059	   found in BCP 78 and BCP 79.

1061	   Copies of IPR disclosures made to the IETF Secretariat and any
1062	   assurances of licenses to be made available, or the result of an
1063	   attempt made to obtain a general license or permission for the use of
1064	   such proprietary rights by implementers or users of this
1065	   specification can be obtained from the IETF on-line IPR repository at
1066	   http://www.ietf.org/ipr.

1068	   The IETF invites any interested party to bring to its attention any
1069	   copyrights, patents or patent applications, or other proprietary
1070	   rights that may cover technology that may be required to implement
1071	   this standard.  Please address the information to the IETF at
1072	   ietf-ipr@ietf.org.

1074	Disclaimer of Validity

1076	   This document and the information contained herein are provided on an
1077	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1078	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1079	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1080	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1081	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1082	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1084	Copyright Statement

1086	   Copyright (C) The Internet Society (2005).  This document is subject
1087	   to the rights, licenses and restrictions contained in BCP 78, and
1088	   except as set forth therein, the authors retain all their rights.

1090	Acknowledgment

1092	   Funding for the RFC Editor function is currently provided by the
1093	   Internet Society.