idnits 2.17.1 draft-ietf-simple-event-filter-funct-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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 488 has weird spacing: '...pplying the f...' == 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 (June 22, 2004) is 7241 days in the past. Is this intentional? 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. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-01 == Outdated reference: A later version (-05) exists of draft-ietf-simple-filter-format-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE H. Khartabil 2 Internet-Draft E. Leppanen 3 Expires: December 21, 2004 M. Lonnfors 4 J. Costa-Requena 5 Nokia 6 June 22, 2004 8 Functional Description of Event Notification Filtering 9 draft-ietf-simple-event-filter-funct-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 21, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 The SIP event notification framework describes the usage of the 41 Session Initiation Protocol (SIP) for subscriptions and notifications 42 of changes to a state of a resource. The document does not describe 43 a mechanism of how filtering of event notification information can be 44 achieved. 46 This document describes the operations a subscriber performs in order 47 to define filtering rules, how to handle responses to subscriptions 48 carrying filtering rules, and how to handle notifications with 49 filtering rules applied to them. The document also describes how the 50 notifier behaves when receiving such filtering rules and how a 51 notification is constructed. 53 The format of the filter is outside the scope of this document. 55 Table of Contents 57 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Client Operation . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1 Transport Mechanism . . . . . . . . . . . . . . . . . . . 4 61 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 62 3.3 Subscriber Generating SUBSCRIBE Requests . . . . . . . . . 5 63 3.3.1 Structure of a Filter . . . . . . . . . . . . . . . . 5 64 3.3.2 Request-URI vs. Filter URI . . . . . . . . . . . . . . 6 65 3.3.3 Changing Filters within a Dialog . . . . . . . . . . . 6 66 3.3.4 Subscriber Interpreting SIP responses . . . . . . . . 7 67 3.4 Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 68 4. Resource List Server Behaviour . . . . . . . . . . . . . . . . 7 69 4.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . 7 70 4.2 Changing Filters within a Dialog . . . . . . . . . . . . . 9 71 5. Server Operation . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 73 5.2 Notifier Processing SUBSCRIBE Requests . . . . . . . . . . 10 74 5.2.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . 11 75 5.2.2 Changing Filters within a Dialog . . . . . . . . . . . 11 76 5.3 Notifier Generating NOTIFY Requests . . . . . . . . . . . 11 77 5.3.1 Generation of NOTIFY Contents . . . . . . . . . . . . 12 78 5.3.2 Handling of Notification Triggering Rules . . . . . . 13 79 5.4 Handling Abnormal Cases . . . . . . . . . . . . . . . . . 13 80 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.1 Presence Specific Examples . . . . . . . . . . . . . . . . 13 82 6.1.1 Subscriber Requests Messaging Related Information . . 14 83 6.1.2 Subscriber Fetches Information about "Open" 84 Communication Means . . . . . . . . . . . . . . . . . 16 85 6.1.3 Subscriber Requests Notifications when 86 Presentity's Status Changes . . . . . . . . . . . . . 17 87 6.2 Watcher Information Specific Examples . . . . . . . . . . 20 88 6.2.1 Watcher Subscriber Makes Subscription to Get All 89 the Information about Active Watchers . . . . . . . . 21 90 6.2.2 Watcher Subscriber Requests Information of 91 Watchers with Specific Subscription Duration 92 Conditions . . . . . . . . . . . . . . . . . . . . . . 22 93 6.2.3 Watcher Subscriber Requests Specific Watcher Info 94 On Specific Triggers . . . . . . . . . . . . . . . . . 23 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 100 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 102 Intellectual Property and Copyright Statements . . . . . . . . 29 104 1. Conventions 106 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 107 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 108 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 109 and indicate requirement levels for compliant implementations. 111 2. Introduction 113 SIP event notification is described in [3]. It defines a general 114 framework for sending subscriptions and receiving notifications in 115 SIP based systems. It introduces the concept of event packages, 116 which are concrete applications of the general event framework to a 117 specific usage of events. 119 Filtering is a mechanism for controlling the content of event 120 notifications. Additionally, the subscriber may specify the rules 121 for when a notification should be sent to it. The filtering 122 mechanism is expected to be particularly valuable to users of mobile 123 wireless access devices. The characteristics of the devices 124 typically include high latency, low bandwidth, low data processing 125 capabilities, small display, and limited battery power. Such devices 126 can benefit from the ability to filter the amount of information 127 generated at the source of the event notification. 129 It is stated in [3] that the notifier may send a NOTIFY at any time, 130 but typically it is sent when the state of the resource changes. It 131 also states that the notifications would contain the complete and 132 current state of the resource authorized for a certain subscriber to 133 see. The format of such resource state information is package 134 specific. In this memo, we assume that the NOTIFY for any package 135 contains an XML document. 137 This document presents a mechanism for filtering whereby a subscriber 138 describes its preference of when notifications are to be sent to it 139 and what they are to contain. It also describes how the notifier 140 functions when generating notifications by taking into account 141 filters and default functionality of the package/service. 143 The XML format for defining the filter is described in [5]. 145 3. Client Operation 147 3.1 Transport Mechanism 149 Transportation of the filter to the server is achieved by inserting 150 the XML document, as defined in [5], in the body of the SUBSCRIBE 151 request. Alternatively, the XML document can be uploaded to the 152 server using means outside the scope of this document. 154 3.2 SUBSCRIBE Bodies 156 SIP entities compliant with this specification MUST support the 157 content type 'application/simple-filter+xml'. 159 3.3 Subscriber Generating SUBSCRIBE Requests 161 This section presents additional functionality required from the 162 subscriber when filters are used in the bodies of the SUBSCRIBE 163 requests. Normal operations of services, e.g., as defined in [7], 164 [9] and [4] are otherwise followed. 166 As defined in [3], the SUBSCRIBE message MAY contain a body. This 167 body would serve the purpose of carrying filtering information. 168 Honouring those filters is at the discretion of the notifier and 169 might depend on local policies. 171 No content in the body of a SUBSCRIBE indicates to the notifier that 172 no filter is being requested so that the notifier is instructed to 173 send all the NOTIFY requests using the notifier's own or service 174 specific policy. Note that e.g. in the list case [4] the filter 175 might have been uploaded to the server beforehand (by means outside 176 the scope of this document). 178 If the body of the SUBSCRIBE includes the filter, the body MUST be of 179 the MIME-Type 'application/simple-filter+xml'. 181 3.3.1 Structure of a Filter 183 Multiple filters MAY be included in one SUBSCRIBE. This is achieved 184 by including multiple elements in the filter [5]. Each 185 element may include a URI attribute. 187 A SUBSCRIBE request destined to a list URI [4] MAY include multiple 188 filters specific to individual resources. This is achieved by 189 including multiple elements with different URIs of resources 190 in each of those elements. This resource specific filter overrides 191 any list specific filter, if any. The list specific filter may or 192 may not include a URI. 194 Furthermore, regardless whether the SUBSCRIBE is destined to a list 195 URI or not, there can only be one filter applicable to a single 196 resource or domain within a single SUBSCRIBE. I.e. Each filter 197 within a subscription MUST uniquely identify one resource or one 198 domain. 200 3.3.2 Request-URI vs. Filter URI 202 The URI in the filter defines the target resource, e.g. in the 203 Presence service case; it is the presentity's presence information to 204 which the filter is applied. The subscriber MAY choose to leave the 205 URI in the filter undefined. If the URI is not defined within the 206 filter, the filter applies to the resource identified in the 207 Request-URI. Similarly, the subscriber MAY define a filter URI. If 208 the Request-URI is a list URI [4], the filter URI MUST be the list 209 URI, a sub-list URI or resource who's URI is one of the URIs that 210 result from a lookup, by an RLS, on the Request-URI. If not, the 211 filter may be ignored or may be rejected. 213 A filter may also be addressed to a domain using the "domain" 214 attribute instead of the "uri" attribute. In this case, the filter 215 applies to resources in that domain. This can be used when a 216 subscription is for a resource that is an event list with many 217 resources from differing domains. If an individual resource specific 218 filter is present along with the domain filter, this resource 219 specific filter overrides any domian specific filter, if any. 221 3.3.3 Changing Filters within a Dialog 223 The client MAY reset or change the filter by re-issuing a new 224 SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the 225 exiting dialog that does not contain a filter is assumed to maintain 226 existing filters. This means that filters are persistent and are 227 only explicitly removed. 229 A client requiring removal of a filter may do so by using the 230 'remove="true"' attribute as defined in [5]. 232 In the case the URI in the filter is that of a list, a client may 233 override the existing filter with a filter for an individual 234 resource, that is part of the list subscribed to earlier, by issuing 235 a new SUBSCRIBE within the existing dialog and including a filter 236 specific for that individual resource. The new filter need not 237 include the original filter since a filter is only removed in the 238 manner indicated above. 240 A filter is replaced by the client re-issuing the filter using the 241 same filter ID and replacing the contents of the filter. Replacing a 242 filter by chaning the filter ID and keeping the resource URI is 243 considered an error since this causes the server to assume that two 244 filters are placed for the same resource. 246 3.3.4 Subscriber Interpreting SIP responses 248 The SUBSCRIBE request will be confirmed with a final response. A 249 200-class responses indicate that the subscription has been accepted, 250 and that a NOTIFY will be sent immediately. A "200" response 251 indicates that the subscription has been accepted and the filter is 252 accepted. A "202" response merely indicates that the subscription 253 has been understood, the content type has been accepted, and that 254 authorization may or may not have been granted. A "202" response 255 also indicates that the filter has not been accepted yet. The 256 acceptance of the filter MAY arrive in a subsequent NOTIFY. 258 A non-200 class final responses indicate that no subscription or 259 dialog has been created, and no subsequent NOTIFY message will be 260 sent. All non-200 class final responses have the same meanings and 261 handling as described in [2] and [3]. 263 Specifically, a "415" response indicates that the MIME type 264 'application/simple-filter+xml' is not understood by the notifier. A 265 "488" response indicates that the content type (filter) is understood 266 but some aspects of it were either not understood or not accepted. 268 3.4 Subscriber Processing of NOTIFY Requests 270 If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that 271 follows MAY contain a body that describes the present state of the 272 resource after the filters have been applied. 274 If the NOTIFY indicates that a subscription has been terminated [3], 275 the subscription is assumed to be terminated. Behaviour in such 276 events is also described in [3]. 278 If the subscription is indicated as active, NOTIFY requests are 279 handled as described in package specific documents and [3]. 281 4. Resource List Server Behaviour 283 The Resource List Server is defined in [4]. This section describes 284 how such entity behaves in the presence of a filter in a subscription 285 to a list. 287 4.1 Request-URI vs. Filter URI 289 If the URI is not defined within the filter, the filter applies to 290 the resource identified in the Request-URI. 292 If no URI is indicated by the filter, the filter applies to all the 293 notifications that the RLS issues. If the URI indicated by the 294 filter is a list URI, the filter applies to all the notifications 295 that the RLS issues. 297 If the URI indicated by the filter is for one resource who's URI is 298 one of the URIs that result from a lookup, by the RLS, on the 299 Request-URI, the filter for that particular resource is extracted and 300 propagated in the SUBSCRIBE request sent to that resource. It is 301 possible to have more than one filter in a SUBSCRIBE request body, 302 and therefore a filter specific to a resource MUST be extracted and 303 only that is propagated. For example, if the Request-URI in a 304 SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where 305 "bob@mydomain.com" is a resource belonging to that list, and the URI 306 in a filter is "sip:bob@mydomain.com", the filter specific for Bob is 307 extracted and placed in the body of the SUBSCRIBE sent to 308 "bob@mydomain.com". 310 If the URI indicated by the filter is for one resource who's URI is 311 NOT under the RLS administrative control, the RLS propagates the 312 filter to all the fanned out subscriptions sent to destinations 313 outside the adminstrative domain of the RLS. This is to accommodate 314 the scenario where the subscriber knows that there are sub-lists in 315 the event list that are under a different administrative domain than 316 where the original subscription was sent to, and the subscriber 317 wishes to set a filter for a resource in that sub-list. There may be 318 situations where the filters were not propagated because they address 319 a URI that in under the adminstrative domain of the RLS, but are not 320 part of the resource list that the subscription was addressed to. In 321 this case, it is the RLS responsibility to make sure than those 322 filters are applied to notifications issued. 324 For example: If we have 2 lists, each located on its own RLS: 326 List1 (list1@example1.com) on RLS1 has: bob@example1.com 327 list2@example2.com 329 List2 on RLS2 has: alice@example2.com sarah@example1.com 330 (Note: list2 is a resource in list1) 332 RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is for 333 addressed to list1and contains 2 filters: one for sarah@example1.com 334 and the other for alice@example2.com): 336 SUBSCRIBE sip:List1@example1.com SIP/2.0 337 ... 338 339 340 341 342 343 urn:ietf:params:xml:ns:pidf 344 345 //pidf:tuple/pidf:note 346 347 348 349 350 351 //pidf:tuple/pidf:status/pidf:basic 352 353 354 356 RLS1 fans out subscriptions to resources on list1. The text above 357 suggests that if a filter is destined to a resource that is not part 358 of the list and is outside the administrative domain of an RLS, then 359 that filter is propagated. The rest are consumed. In our example, 360 only the filter to alice@example2.com is propagated since 361 example2.com is not under the administrative domain of RLS1. The 362 filter to sarah@example1.com is consumed, and RLS1 needs to apply 363 that filter to notifications it receives. 365 A filter may also be addressed to a domain using the "domain" 366 attribute instead of the "uri" attribute. In this case, the filter 367 applies to resources in that domain and the RLS MUST NOT apply 368 filters to any notifications it sends, but instead MUST forward the 369 filter with all fanned out subscriptions to the notifiers. 371 As indicated in Section 3.3.1, multiple filters can be present in a 372 SUBSCRIBE request. Filters can also be added or modified as 373 indicated in Section 3.3.3. In such circumstances, an RLS MUST check 374 that there are no filters addressed to the same resource or domain 375 and if so, it MUST reject the SUBSCRIBE request with a "488" error 376 response. 378 4.2 Changing Filters within a Dialog 380 If an RLS receives a subscription refresh request with no filters 381 specified (empty payload), the RLS assumes that the client does not 382 wish to update the filters. If an RLS receives a subscription 383 refresh with a filter containing the 'remove="true"' attribute as 384 defined in [5], the RLS assumes that the client is removing that 385 filter identified by the filter ID. 387 If an RLS receives a subscription refresh request with a filter that 388 already exists (I.e. having the same filter ID), the RLS interprets 389 it as a replacement oif the existing filter. Replacing a filter by 390 chaning the filter ID and keeping the resource URI is considered an 391 error since this causes the RLS to assume that two filters are placed 392 for the same resource. 394 5. Server Operation 396 5.1 NOTIFY Bodies 398 SIP entities compliant with this specification MUST support 399 content-type 'application/simple-filter+xml'. 401 5.2 Notifier Processing SUBSCRIBE Requests 403 This section presents addition functionality required from the 404 notifier when filters are used in the bodies of the SUBSCRIBE 405 requests. Normal package specific functionality are otherwise 406 followed. 408 The notifier will examine the content type header and will return a 409 415 response if it does not understand the content type 'application/ 410 simple-filter+xml'. 412 A 200-class responses indicate that the subscription has been 413 accepted, and the NOTIFY will be sent immediately. A "200" response 414 indicates that the subscription has been accepted, the user is 415 authorized and the filter is accepted. A "202" response merely 416 indicates that the subscription has been understood, but the 417 authorization may or may not have been granted. A "202" response 418 also indicates that the filters have not been accepted yet. The 419 acceptance of the filters MAY arrive in a subsequent NOTIFY. 421 Procedures described in section Section 5.4 are followed if an error 422 is encountered. 424 As indicated in Section 3.3.1, multiple filters can be present in a 425 SUBSCRIBE request. Filters can also be added or modified as 426 indicated in Section 3.3.3. In such circumstances, a server MUST 427 check that there are no filters addressed to the same resource or 428 domain and if so, it MUST reject the SUBSCRIBE request with a "488" 429 error response. 431 5.2.1 Request-URI vs. Filter URI 433 The subscriber may have chosen to leave the URI in the filter 434 undefined. If the URI is not defined within the filter, the filter 435 applies to the resource identified in the Request-URI. 437 Similarly, the subscriber may have chosen to include a URI in the 438 filter. In this case, the filter applies to all notifications send 439 for this subscription. If the Request-URI and the URI in the filter 440 mismatch, the filter may be ignored or may be rejected. 442 A filter may also be addressed to a domain using the "domain" 443 attribute instead of the "uri" attribute. In this case, the filter 444 applies to resources in that domain. The notifier MUST NOT apply 445 filters to any notifications it sends if the domain is not that of 446 its own, and MUST ignore it. Notifiers belonging to domain MUST 447 apply the filter to all notifications sent, unless policy dictates 448 otherwise. 450 5.2.2 Changing Filters within a Dialog 452 If a server receives a subscription refresh request with no filters 453 specified (empty payload), it assumes that the client does not wish 454 to update the filters. If it receives a subscription refresh with a 455 filter containing the 'remove="true"' attribute as defined in [5], 456 the server assumes that the client is removing that filter identified 457 by the filter ID. 459 If the server receives a subscription refresh request with a filter 460 that already exists (I.e. having the same filter ID), it interprets 461 it as a replacement oif the existing filter. Replacing a filter by 462 chaning the filter ID and keeping the resource URI is considered an 463 error since this causes the server to assume that two filters are 464 placed for the same resource. 466 5.3 Notifier Generating NOTIFY Requests 468 Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD 469 retain the filter as long as the subscription persists. The filter 470 MAY be incorporated within an existing subscription (in an active 471 dialog) by sending a re-SUBSCRIBE that includes the filter in the 472 body. 474 If the response sent to the SUBSCRIBE was the 202 and the 202 was 475 chosen because the filter could not be accepted that time, the NOTIFY 476 MAY be used to terminate the subscription if the filter was found 477 unacceptable. 479 As described in [3], the NOTIFY message MAY contain a body that 480 describes the state of the resource. This body is in one of the 481 formats listed in the Accept header of the SUBSCRIBE, or the package 482 specific default if the Accept header is omitted. 484 5.3.1 Generation of NOTIFY Contents 486 If the NOTIFY being sent is the immediate one sent after a 2xx 487 response to the original SUBSCRIBE, its contents MUST be populated 488 according to the filter. If applying the filter results in not 489 sending a NOTIFY, the NOTIFY MUST be sent with empty contents. A 490 notifier may also choose not to obey the filter in the first NOTIFY 491 and instead send the configured value authorised for that subscriber 492 set by the notifier using means outside the scope of this document). 494 The input to the content filter is a package specific XML document, 495 e.g. [6] and [8] derived according to the package specific 496 specifications, ([7] and [9]). 498 The content is filtered according to the expressions in the 499 element of the filter. The expression indicates the delivered XML 500 elements and/or attributes. Prefixes of the namespaces of the items 501 of the XML document to be filtered must be expanded before applying 502 the filter to the items. 504 The expression directly states the XML elements and attributes to be 505 delivered in the NOTIFY, along with their values. In addition to the 506 selected contents also the namespaces of all the selected items are 507 included in the NOTIFY. The XML elements and/or attributes indicated 508 by the expression in the element must be items that the 509 subscriber is authorised to see. If not, the notifier policy 510 dictates the behaviour of the notifier (notifier can either ignore 511 the filter, parts of the filter, or reject the filter completely). 512 Implementers need to carefully consider such an implementation 513 decision; the subscriber may not be aware of the authorised contents 514 and therefore most likely will include a filter requesting 515 unauthorised contents. It is therefore RECOMMENDED that notifiers 516 just ignores the parts of the filter where it is requesting 517 unauthorised info. I.e. The filter in the element where 518 the unauthorised contents are requested is ignored. If polite 519 blocking is used by the notifier, the notifier may choose to ignore 520 the filter, by choosing to deliver notifications containing bogus 521 information in the unauthorised elements or attributes. 523 The resultant XML document MUST be well formed and valid according to 524 the XML schema. This means that all mandatory elements and 525 attributes along with their values MUST be included in the XML 526 document regardless of the expression. In other words, if the 527 results of applying a filter on an XML document is a non-valid XML 528 document, the notifier MUST add elements and attributes, along with 529 their values, from the original XML document into the newly 530 formulated one in order for it to be a valid one. 532 5.3.2 Handling of Notification Triggering Rules 534 There can be several elements inside one element. 535 If the criteria for any of the elements are satisfied, a 536 NOTIFY SHOULD be generated. 538 The items (XML elements and/or attributes) indicated by the 539 expression in the element, element or 540 element must be items that the subscriber is authorised to access. 541 If not, the notifier policy dictates the behaviour of the notifier 542 (notifier can either ignore the filter, parts of the filter, or 543 reject the filter completely). 545 5.4 Handling Abnormal Cases 547 In case of an invalid filter definition where the XML document of the 548 filter is not aligned with the XML schema of the filter format[5], 549 the notifier rejects the SUBSCRIBE request with a "488" response. A 550 warning header in the response may give better indication why the 551 filters were not accepted. If the subscription was accepted with a 552 "202" response but the invalid filter was discovered after that, a 553 NOTIFY with a subscription-state of value 'terminated' is sent. An 554 event-reason-value "badfilter", introduced here, of subexp-params [3] 555 MAY be included. 557 In case of an erroneous expression in the filter definition the 558 notifier either ignores the filter definition or terminates the 559 subscription. 561 If a or element is empty, the notifier proceeds as 562 if the element did not exist. 564 6. Examples 566 The following chapters include filtering examples for Presence and 567 Watcher Information. The format of filter is according to [5]. 569 6.1 Presence Specific Examples 571 This chapter describes three use cases where the presence information 572 filtering solution is utilised [7]. In the first use case the 573 watcher is interested in getting messaging specific information of a 574 certain presentity. In the second use case the watcher is interested 575 in getting information about the communication means and contact 576 addresses the presentity is currently available for communication on. 577 The third case shows how a presentity can request triggers to receive 578 notifications 580 Below is the Presentity's presence information in PIDF [6]. It 581 includes two tuples: one for the instant messaging and another for 582 the voice related information. 583 584 587 588 589 closed 590 591 im 592 im:presentity@domain.com 593 594 595 596 open 597 598 voice 599 tel:2224055555@domain.com 600 601 603 6.1.1 Subscriber Requests Messaging Related Information 605 The subscriber initiates a subscription to the presentity's messaging 606 (MMS, IM and SMS) related presence information. The subscription 607 includes the content limiting filter. 609 The filtered content is indicated with an expression. This 610 expression selects the element and all the parent elements 611 (this means the status, tuple and its root element), the 612 element and the element. The filter is: elements 613 that have values beginning with "MMS", "SMS" or "IM". 615 In this case, the notification includes the contents of the tuple 616 that has the value "IM" in its