idnits 2.17.1 draft-ietf-simple-event-filter-funct-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1371. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages 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 == 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 (January 14, 2005) is 7035 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 (-05) exists of draft-ietf-simple-filter-format-04 ** Obsolete normative reference: RFC 2633 (ref. '6') (Obsoleted by RFC 3851) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: July 15, 2005 E. Leppanen 5 M. Lonnfors 6 J. Costa-Requena 7 Nokia 8 January 14, 2005 10 Functional Description of Event Notification Filtering 11 draft-ietf-simple-event-filter-funct-04 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 15, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The SIP event notification framework describes the usage of the 47 Session Initiation Protocol (SIP) for subscriptions and notifications 48 of changes to a state of a resource. The document does not describe 49 a mechanism of how filtering of event notification information can be 50 achieved. 52 This document describes the operations a subscriber performs in order 53 to define filtering rules associated with event notification 54 information. The handling of responses to subscriptions carrying 55 filtering rules and the handling of notifications with filtering 56 rules applied to them is described. The document also describes how 57 the notifier behaves when receiving such filtering rules and how a 58 notification is constructed. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Client Operation . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1 Transport Mechanism . . . . . . . . . . . . . . . . . . . 5 66 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 67 3.3 Subscriber Generating SUBSCRIBE Requests . . . . . . . . . 5 68 3.3.1 Structure of a Filter . . . . . . . . . . . . . . . . 5 69 3.3.2 Request-URI vs. Filter URI . . . . . . . . . . . . . . 6 70 3.3.3 Changing Filters within a Dialog . . . . . . . . . . . 6 71 3.3.4 Subscriber Interpreting SIP responses . . . . . . . . 7 72 3.4 Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 73 4. Resource List Server Behaviour . . . . . . . . . . . . . . . . 8 74 4.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . 8 75 4.2 Changing Filters within a Dialog . . . . . . . . . . . . . 10 76 5. Server Operation . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2 Notifier Processing SUBSCRIBE Requests . . . . . . . . . . 10 79 5.2.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . 11 80 5.2.2 Changing Filters within a Dialog . . . . . . . . . . . 11 81 5.3 Notifier Generating NOTIFY Requests . . . . . . . . . . . 12 82 5.3.1 Generation of NOTIFY Contents . . . . . . . . . . . . 13 83 5.3.2 Handling of Notification Triggering Rules . . . . . . 14 84 5.4 Handling Abnormal Cases . . . . . . . . . . . . . . . . . 14 85 6. XML Document Validation . . . . . . . . . . . . . . . . . . . 14 86 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.1 Presence Specific Examples . . . . . . . . . . . . . . . . 15 88 7.1.1 Subscriber Requests Messaging Related Information . . 15 89 7.1.2 Subscriber Fetches Information about "Open" 90 Communication Means . . . . . . . . . . . . . . . . . 17 91 7.1.3 Subscriber Requests Notifications when 92 Presentity's Status Changes . . . . . . . . . . . . . 19 93 7.2 Watcher Information Specific Examples . . . . . . . . . . 21 94 7.2.1 Watcher Subscriber Makes Subscription to Get All 95 the Information about Active Watchers . . . . . . . . 22 96 7.2.2 Watcher Subscriber Requests Information of 97 Watchers with Specific Subscription Duration 98 Conditions . . . . . . . . . . . . . . . . . . . . . . 24 99 7.2.3 Watcher Subscriber Requests Specific Watcher Info 100 On Specific Triggers . . . . . . . . . . . . . . . . . 25 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 28 106 11.2 Informative References . . . . . . . . . . . . . . . . . . . 29 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 108 Intellectual Property and Copyright Statements . . . . . . . . 31 110 1. Introduction 112 SIP event notification is described in [3]. It defines a general 113 framework for sending subscriptions and receiving notifications in 114 SIP based systems. It introduces the concept of event packages, 115 which are concrete applications of the general event framework to a 116 specific usage of events. 118 Filtering is a mechanism for controlling the content of event 119 notifications. Additionally, the subscriber may specify the rules 120 for when a notification should be sent to it. The filtering 121 mechanism is expected to be particularly valuable to users of mobile 122 wireless access devices. The characteristics of the devices 123 typically include high latency, low bandwidth, low data processing 124 capabilities, small display, and limited battery power. Such devices 125 can benefit from the ability to filter the amount of information 126 generated at the source of the event notification. However, 127 implementers need to be aware of the computational burden on the 128 source of the event notification. This is discussed further in 129 Section 8. 131 It is stated in [3] that the notifier may send a NOTIFY at any time, 132 but typically it is sent when the state of the resource changes. It 133 also states that the notifications would contain the complete and 134 current state of the resource authorized for a certain subscriber to 135 see. The format of such resource state information is package 136 specific. In this memo, we assume that the NOTIFY for any package 137 contains an XML document. 139 This document presents a mechanism for filtering whereby a subscriber 140 describes its preference of when notifications are to be sent to it 141 and what they are to contain. It also describes how the notifier 142 functions when generating notifications by taking into account 143 filters and default functionality of the package/service. 145 The XML format for defining the filter is described in [5]. 147 2. Conventions 149 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 150 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 151 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 152 and indicate requirement levels for compliant implementations. 154 "Content" refers to the XML document that appears in a notification 155 reflecting the state of a resource. 157 3. Client Operation 159 3.1 Transport Mechanism 161 Transportation of the filter to the server is achieved by inserting 162 the XML document, as defined in [5], in the body of the SUBSCRIBE 163 request. Alternatively, the XML document can be uploaded to the 164 server using means outside the scope of this document. 166 3.2 SUBSCRIBE Bodies 168 SIP entities compliant with this specification MUST support the 169 content type 'application/simple-filter+xml'. 171 3.3 Subscriber Generating SUBSCRIBE Requests 173 This section presents additional functionality required from the 174 subscriber when filters are used in the bodies of the SUBSCRIBE 175 requests. Normal operations of services, e.g., as defined in [8], 176 [10] and [4] are otherwise followed. 178 As defined in [3], the SUBSCRIBE message MAY contain a body. This 179 body would serve the purpose of carrying filtering information. 180 Honouring those filters is at the discretion of the notifier and 181 might depend on local policies. 183 No content in the body of a SUBSCRIBE indicates to the notifier that 184 no filter is being requested so that the notifier is instructed to 185 send all the NOTIFY requests using the notifier's own or service 186 specific policy. Note that e.g. in the list case [4] the filter 187 might have been uploaded to the server beforehand (by means outside 188 the scope of this document). 190 If the body of the SUBSCRIBE includes the filter, the body MUST be of 191 the MIME-Type 'application/simple-filter+xml'. 193 3.3.1 Structure of a Filter 195 Multiple filters MAY be included in one SUBSCRIBE. This is achieved 196 by including multiple elements in the filter [5]. Each 197 element may include a URI attribute. 199 A SUBSCRIBE request destined to a list URI [4] MAY include multiple 200 filters specific to individual resources. This is achieved by 201 including multiple elements with different URIs of resources 202 in each of those elements. This resource specific filter overrides 203 any list specific filter, if any. The list specific filter may or 204 may not include a URI. 206 Furthermore, regardless whether the SUBSCRIBE is destined to a list 207 URI or not, there can only be one filter applicable to a single 208 resource or domain within a single SUBSCRIBE. I.e. Each filter 209 within a subscription MUST uniquely identify one resource or one 210 domain. 212 A filter can be disabled by setting the 'enabled' attribute in the 213 element to "false". When a filter is disabled by setting 214 the 'enabled' attribute to "false", the and elements 215 MAY be omitted. Similarily, when a filter is re-enabled by setting 216 the 'enabled' attribute to "true", the and elements 217 MAY be omitted. 219 3.3.2 Request-URI vs. Filter URI 221 The URI in the filter defines the target resource, e.g. in the 222 Presence service case; it is the presentity's presence information to 223 which the filter is applied. The subscriber MAY choose to leave the 224 URI in the filter undefined. If the URI is not defined within the 225 filter, the filter applies to the resource identified in the 226 Request-URI. Similarly, the subscriber MAY define a filter URI. If 227 the Request-URI is a list URI [4], the filter URI MUST be the list 228 URI, a sub-list URI or resource who's URI is one of the URIs that 229 result from a lookup, by an RLS, on the Request-URI. If not, the 230 filter may be ignored or may be rejected. URI matching is done 231 according to the matching rules defined for a particular scheme (SIP 232 URI matching rules are defined in RFC3261 [2]. 234 A filter may also be addressed to a domain using the "domain" 235 attribute instead of the "uri" attribute. In this case, the filter 236 applies to resources in that domain. This can be used when a 237 subscription is for a resource that is an event list with many 238 resources from differing domains. If an individual resource specific 239 filter is present along with the domain filter, this resource 240 specific filter overrides any domain specific filter, if any. 242 3.3.3 Changing Filters within a Dialog 244 The client MAY reset or change the filter by re-issuing a new 245 SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the 246 exiting dialog that does not contain a filter is assumed to maintain 247 existing filters. This means that filters are persistent and are 248 only explicitly removed. 250 A client requiring removal of a filter may do so by using the 251 'remove="true"' attribute as defined in [5]. 253 In the case the URI in the filter is that of a list, a client may 254 override the existing filter with a filter for an individual 255 resource, that is part of the list subscribed to earlier, by issuing 256 a new SUBSCRIBE within the existing dialog and including a filter 257 specific for that individual resource. The new filter need not 258 include the original filter since a filter is only removed in the 259 manner indicated above. 261 A filter is replaced by the client re-issuing the filter using the 262 same filter ID and replacing the contents of the filter. Replacing a 263 filter by changing the filter ID and keeping the resource URI is 264 considered an error since this causes the server to assume that two 265 filters are placed for the same resource. 267 3.3.4 Subscriber Interpreting SIP responses 269 The SUBSCRIBE request will be confirmed with a final response. A 270 200-class responses indicate that the subscription has been accepted, 271 and that a NOTIFY will be sent immediately. A "200" response 272 indicates that the subscription has been accepted and the filter is 273 accepted. A "202" response merely indicates that the subscription 274 has been understood, the content type has been accepted, and that 275 authorization may or may not have been granted. A "202" response 276 also indicates that the filter has not been accepted yet. The 277 acceptance of the filter MAY arrive in a subsequent NOTIFY. 279 A non-200 class final responses indicate that no subscription or 280 dialog has been created, and no subsequent NOTIFY message will be 281 sent. All non-200 class final responses have the same meanings and 282 handling as described in [2] and [3]. 284 Specifically, a "415" response indicates that the MIME type 285 'application/simple-filter+xml' is not understood by the notifier. A 286 "488" response indicates that the content type (filter) is understood 287 but some aspects of it were either not understood or not accepted. 289 3.4 Subscriber Processing of NOTIFY Requests 291 If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that 292 follows MAY contain a body that describes the present state of the 293 resource after the filters have been applied. 295 If the NOTIFY indicates that a subscription has been terminated [3], 296 the subscription is assumed to be terminated. Behaviour in such 297 events is also described in [3]. 299 If the subscription is indicated as active, NOTIFY requests are 300 handled as described in package specific documents and [3]. 302 4. Resource List Server Behaviour 304 The Resource List Server is defined in [4]. This section describes 305 how such entity behaves in the presence of a filter in a subscription 306 to a list. 308 4.1 Request-URI vs. Filter URI 310 If the URI is not defined within the filter, the filter applies to 311 the resource list identified in the Request-URI of the SUBSCRIBE 312 request. This results in the filter being applied to all the 313 notifications that the RLS issues to this subscription. The same 314 processing applies to a filter that defines a URI that matches the 315 request-URI of the SUBSCRIBE request. I.e. The filter applies to 316 all notifications that the RLS issues to this subscription. 318 If the URI indicated by the filter is for one resource whose URI is 319 one of the URIs that result from a lookup, by the RLS, on the 320 Request-URI, the filter for that particular resource is extracted and 321 propagated in the SUBSCRIBE request sent to that resource. It is 322 possible to have more than one filter in a SUBSCRIBE request body, 323 and therefore a filter specific to a resource MUST be extracted and 324 only that is propagated. For example, if the Request-URI in a 325 SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where 326 "bob@mydomain.com" is a resource belonging to that list, and the URI 327 in a filter is "sip:bob@mydomain.com", the filter specific for Bob is 328 extracted and placed in the body of the SUBSCRIBE sent to 329 "bob@mydomain.com". 331 If the URI indicated by the filter is for one resource whose URI is 332 NOT under the RLS administrative control, the RLS propagates the 333 filter to all the fanned out subscriptions sent to destinations 334 outside the administrative domain of the RLS. This is to accommodate 335 the scenario where the subscriber knows that there are sub-lists in 336 the event list that are under a different administrative domain than 337 where the original subscription was sent to, and the subscriber 338 wishes to set a filter for a resource in that sub-list. 340 If the URI indicated by the filter is for one resource whose URI is 341 under the RLS administrative control but is not part of the resource 342 list that the subscription was addressed to, the filter is not 343 propagated. In this case, it is the RLS responsibility to make sure 344 than this filter is applied to notifications issued, if information 345 about that resource is present. 347 For example: If we have 2 lists, each located on its own RLS: 349 List1 (list1@example1.com) on RLS1 has: bob@example1.com 350 list2@example2.com 352 List2 on RLS2 has: alice@example2.com sarah@example1.com 353 (Note: list2 is a resource in list1) 355 RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is for 356 addressed to list1 and contains 2 filters: one for sarah@example1.com 357 and the other for alice@example2.com): 359 SUBSCRIBE sip:List1@example1.com SIP/2.0 360 ... 361 362 363 364 365 366 367 368 369 urn:ietf:params:xml:ns:pidf 370 371 //pidf:tuple/pidf:note 372 373 374 375 376 377 //pidf:tuple/pidf:status/pidf:basic 378 379 380 382 RLS1 fans out subscriptions to resources on list1. The text above 383 suggests that if a filter is destined to a resource that is not part 384 of the list and is outside the administrative domain of an RLS, then 385 that filter is propagated. The rest are consumed. In our example, 386 only the filter to alice@example2.com is propagated since 387 example2.com is not under the administrative domain of RLS1. The 388 filter to sarah@example1.com is consumed, and RLS1 needs to apply 389 that filter to notifications it receives. 391 URI matching is done according to the matching rules defined for a 392 particular scheme (SIP URI matching rules are defined in RFC3261 393 [2]. 395 A filter may also be addressed to a domain using the "domain" 396 attribute instead of the "uri" attribute. In this case, the filter 397 applies to resources in that domain and the RLS MUST NOT apply 398 filters to any notifications it sends, but instead MUST forward the 399 filter with all fanned out subscriptions to the notifiers. 401 As indicated in Section 3.3.1, multiple filters can be present in a 402 SUBSCRIBE request. Filters can also be added or modified as 403 indicated in Section 3.3.3. In such circumstances, an RLS MUST check 404 that there are no filters addressed to the same resource or domain 405 and if so, it MUST reject the SUBSCRIBE request with a "488" error 406 response. 408 4.2 Changing Filters within a Dialog 410 If an RLS receives a subscription refresh request with no filters 411 specified (empty payload), the RLS assumes that the client does not 412 wish to update the filters. If an RLS receives a subscription 413 refresh with a filter containing the 'remove="true"' attribute as 414 defined in [5], the RLS assumes that the client is removing that 415 filter identified by the filter ID. 417 If an RLS receives a subscription refresh request with a filter that 418 already exists (i.e. having the same filter ID), the RLS interprets 419 it as a replacement of the existing filter. Replacing a filter by 420 changing the filter ID and keeping the resource URI is considered an 421 error since this causes the RLS to assume that two filters are placed 422 for the same resource. 424 5. Server Operation 426 5.1 NOTIFY Bodies 428 SIP entities compliant with this specification MUST support 429 content-type 'application/simple-filter+xml'. 431 5.2 Notifier Processing SUBSCRIBE Requests 433 This section presents additional functionality required from the 434 notifier when filters are used in the bodies of the SUBSCRIBE 435 requests. Normal package specific functionality are otherwise 436 followed. 438 The notifier will examine the Content-Type header field and will 439 return a 415 response if it does not understand the content type 440 'application/simple-filter+xml'. 442 A 200-class responses indicate that the subscription has been 443 accepted, and the NOTIFY will be sent immediately. A "200" response 444 indicates that the subscription has been accepted, the user is 445 authorized and the filter is accepted. A "202" response merely 446 indicates that the subscription has been understood, but the 447 authorization may or may not have been granted. A "202" response 448 also indicates that the filters have not been accepted yet. The 449 acceptance of the filters MAY arrive in a subsequent NOTIFY. 451 Procedures described in section Section 5.4 are followed if an error 452 is encountered. 454 As indicated in Section 3.3.1, multiple filters can be present in a 455 SUBSCRIBE request. Filters can also be added or modified as 456 indicated in Section 3.3.3. In such circumstances, a server MUST 457 check that there are no filters addressed to the same resource or 458 domain and if so, it MUST reject the SUBSCRIBE request with a "488" 459 error response. 461 5.2.1 Request-URI vs. Filter URI 463 The subscriber may have chosen to leave the URI in the filter 464 undefined. If the URI is not defined within the filter, the filter 465 applies to the resource identified in the Request-URI. 467 Similarly, the subscriber may have chosen to include a URI in the 468 filter. In this case, the filter applies to all notifications sent 469 with content associated with the resource with that URI, for this 470 subscription. If the Request-URI and the URI in the filter mismatch, 471 the filter may be ignored or may be rejected. URI matching is done 472 according to the matching rules defined for a particular scheme (SIP 473 URI matching rules are defined in RFC3261 [2]. 475 A filter may also be addressed to a domain using the "domain" 476 attribute instead of the "uri" attribute. In this case, the filter 477 applies to resources in that domain. The notifier MUST NOT apply 478 filters to any notifications it sends if the domain is not that of 479 its own, and MUST ignore it. Notifiers belonging to the domain MUST 480 apply the filter to all notifications it sends for that subscription, 481 unless policy dictates otherwise. 483 5.2.2 Changing Filters within a Dialog 485 If a server receives a subscription refresh request with no filters 486 specified (empty payload), it assumes that the client does not wish 487 to update the filters. If it receives a subscription refresh with a 488 filter containing the 'remove="true"' attribute as defined in [5], 489 the server assumes that the client is removing that filter identified 490 by the filter ID. 492 If the server receives a subscription refresh request with a filter 493 that already exists (i.e. having the same filter ID), it interprets 494 it as a replacement of the existing filter. Replacing a filter by 495 changing the filter ID and keeping the resource URI is considered an 496 error since this causes the server to assume that two filters are 497 placed for the same resource. 499 5.3 Notifier Generating NOTIFY Requests 501 Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD 502 retain the filter as long as the subscription persists. The filter 503 MAY be incorporated within an existing subscription (in an active 504 dialog) by sending a re-SUBSCRIBE that includes the filter in the 505 body. 507 If the response sent to the SUBSCRIBE was a "202" and the "202" was 508 chosen because the filter could not be accepted that time, the NOTIFY 509 MAY be used to terminate the subscription if the filter was found 510 unacceptable. 512 As described in [3], the NOTIFY message MAY contain a body that 513 describes the state of the resource. This body is in one of the 514 formats listed in the Accept header field of the SUBSCRIBE, or the 515 package specific default if the Accept header field is omitted. 517 Based on the contects of a filter, the following processing occurs: 519 o A filter with only a element will result in sending the 520 requested resource state information in that element 521 whenever there is a change in the resource state. 523 o A filter with only a element will result in sending all 524 resource state information whenever there is a change in the 525 resource state that matches the triggers. 527 o A filter with a and elements will result in 528 sending the requested resource state information in that 529 element whenever there is a change in the resource state that 530 matches the triggers. 532 When a filter is disabled (by setting the 'enabled' attribute to 533 "false"), all state and state changes are reported. A disabled 534 filter means the same thing as the absence of that filter. I.e. All 535 changes to a resource state result in issuing a notification to the 536 subscriber (assuming there are no other filters). 538 When a filter is re-enabled, (by setting the 'enabled' attribute to 539 "true", or by omitting the 'enabled' attribute), the notifier behaves 540 as if the fliter has just been placed by the SUBSCRIBE request 541 enabling it. Immediate NOTIFY rules as stated in Section 5.3.1 542 apply. 544 5.3.1 Generation of NOTIFY Contents 546 If the NOTIFY being sent is the immediate one sent after a 2xx 547 response to the original SUBSCRIBE, its contents MUST be populated 548 according to the filter element unless the processing of the 549 filters will take too long or the NOTIFY request is following a "202" 550 response to the SUBSCRIBE request and is terminating the 551 subscription. In the case that the fliter is taking too long to 552 process, the NOTIFY request being sent may be empty or may be 553 populated with a pre-configured value as authorised to that 554 subscriber. If applying the filter results in no content to be 555 delivered, the NOTIFY MUST be sent with empty contents. If the 556 fliter contains elements, the notifier ignores the trigger 557 values when generating the first NOTIFY request. 559 The input to the content filter is a package specific XML document, 560 e.g. [7] and [9] derived according to the package specific 561 specifications, ([8] and [10]). 563 The content is filtered according to the expressions in the 564 element of the filter. The expression indicates the delivered XML 565 elements and/or attributes. Prefixes of the namespaces of the items 566 of the XML document to be filtered must be expanded before applying 567 the filter to the items. 569 The expression directly states the XML elements and attributes to be 570 delivered in the NOTIFY, along with their values. In addition to the 571 selected contents also the namespaces of all the selected items are 572 included in the NOTIFY. The XML elements and/or attributes indicated 573 by the expression in the element must be items that the 574 subscriber is authorised to see. If not, the notifier policy 575 dictates the behaviour of the notifier (notifier can either ignore 576 the filter, parts of the filter, or reject the filter completely). 577 Implementers need to carefully consider such an implementation 578 decision; the subscriber may not be aware of the authorised contents 579 and therefore most likely will include a filter requesting 580 unauthorised contents. It is therefore RECOMMENDED that notifiers 581 just ignore the parts of the filter where it is requesting 582 unauthorised info. I.e. The filter in the element where 583 the unauthorised contents are requested is ignored. If polite 584 blocking is used by the notifier, the notifier may choose to ignore 585 the filter, by choosing to deliver notifications containing bogus 586 information in the unauthorised elements or attributes. 588 The resultant XML document MUST be well formed and valid according to 589 the XML schema. This means that all mandatory elements and 590 attributes along with their values MUST be included in the XML 591 document regardless of the expression. In other words, if the 592 results of applying a filter on an XML document is a non-valid XML 593 document, the notifier MUST add elements and attributes, along with 594 their values, from the original XML document into the newly 595 formulated one in order for it to be a valid one. 597 5.3.2 Handling of Notification Triggering Rules 599 There can be several elements inside one element. 600 If the criteria for any of the elements are satisfied, a 601 NOTIFY SHOULD be generated. 603 The items (XML elements and/or attributes) indicated by the 604 expression in the element, element or 605 element must be items that the subscriber is authorised to access. 606 If not, the notifier policy dictates the behaviour of the notifier 607 (notifier can either ignore the filter, parts of the filter, or 608 reject the filter completely). 610 5.4 Handling Abnormal Cases 612 In case of an invalid filter definition where the XML document of the 613 filter is not aligned with the XML schema of the filter format[5], 614 the notifier rejects the SUBSCRIBE request with a "488" response. A 615 Warning header field in the response may give better indication why 616 the filters were not accepted. If the subscription was accepted with 617 a "202" response but the invalid filter was discovered after that, a 618 NOTIFY with a subscription-state of value 'terminated' is sent. An 619 event-reason-value "badfilter", introduced here, of subexp-params [3] 620 MAY be included. 622 In case of an erroneous expression in the filter definition the 623 notifier either ignores the filter definition or terminates the 624 subscription. 626 If a or element is empty, the notifier proceeds as 627 if the element did not exist. 629 6. XML Document Validation 631 7. Examples 633 The following chapters include filtering examples for Presence and 634 Watcher Information. The format of filter is according to [5]. 636 7.1 Presence Specific Examples 638 This chapter describes three use cases where the presence information 639 filtering solution is utilised [8]. In the first use case the 640 watcher is interested in getting messaging specific information of a 641 certain presentity. In the second use case the watcher is interested 642 in getting information about the communication means and contact 643 addresses the presentity is currently available for communication on. 644 The third case shows how a presentity can request triggers to receive 645 notifications 647 Below is the Presentity's presence information in PIDF [7]. It 648 includes two tuples: one for the instant messaging and another for 649 the voice related information. 650 651 654 655 656 closed 657 658 im 659 im:presentity@domain.com 660 661 662 663 open 664 665 voice 666 tel:2224055555@domain.com 667 668 670 7.1.1 Subscriber Requests Messaging Related Information 672 The subscriber initiates a subscription to the presentity's messaging 673 (MMS, IM and SMS) related presence information. The subscription 674 includes the content limiting filter. 676 The filtered content is indicated with an expression. This 677 expression selects the element and all the parent elements 678 (this means the status, tuple and its root element), the 679 element and the element. The filter is: elements 680 that have values beginning with "MMS", "SMS" or "IM". 682 In this case, the notification includes the contents of the tuple 683 that has the value "IM" in its element. 685 SUBSCRIBE request from the subscriber including filter: 687 SUBSCRIBE sip:presentity@domain.com 688 Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 689 To: 690 From: ;tag:12341111 691 Call-ID: 121212@10.0.0.1 692 Cseq: 1 SUBSCRIBE 693 Expires: 3600 694 Event: Presence 695 Contact: 696 Content-Type: application/simple-filter+xml 697 Content-Length: ... 699 700 701 702 703 705 706 707 708 709 //pidf:tuple[rpid:class="IM" or rpid:class="SMS" 710 or rpid:class="MMS"]/pidf:status/pidf:basic 711 712 713 //pidf:tuple[rpid:class="IM" or rpid:class="SMS" 714 or rpid:class="MMS"]/rpid:class 715 716 717 //pidf:tuple[rpid:class="IM" or rpid:class="SMS" 718 or rpid:class="MMS"]/pidf:contact 719 720 721 722 724 Notification to the subscriber: 726 NOTIFY sip:watcher@client.domain.com SIP/2.0 727 Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 728 To: ;tag:12341111 729 From: ;tag:232321 730 Call-ID: 121212@10.0.0.1 731 Cseq: 1 NOTIFY 732 Event: Presence 733 Subscription-State: active; expires=3599 734 Contact: sip:presentity@server.domain.com 735 Content-Type: application/pidf+xml 736 Content-Length: ... 738 739 742 743 744 closed 745 746 im 747 im:presentity@domain.com 748 749 751 7.1.2 Subscriber Fetches Information about "Open" Communication Means 753 The subscriber makes a subscription to the presentity's available 754 communication means. The subscription includes the content limiting 755 filter. 757 The filtered content is indicated with an expression. This 758 expression selects the element and all the parent elements 759 (this means the status, tuple and its root element), the 760 element and the element. The filter is: the 761 element's value is "Open". 763 In this case the notification returns the contents of the tuple that 764 has both the value "open" inside the element. 766 SUBSCRIBE request from the subscriber including filter: 768 SUBSCRIBE sip:presentity@domain.com SIP/2.0 769 Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 770 To: 771 From: ;tag:12341111 772 Call-ID: 121212@10.0.0.1 773 Cseq: 1 SUBSCRIBE 774 Expires: 3600 775 Event: Presence 776 Contact: 777 Content-Type: application/simple-filter+xml 778 Content-Length: ... 780 781 782 783 784 786 787 788 789 790 //pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic 791 792 793 //pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class 794 795 796 //pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact 797 798 799 800 802 Notification to the subscriber: 804 NOTIFY sip:watcher@client.domain.com SIP/2.0 805 Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 806 To: ;tag:12341111 807 From: ;tag:232321 808 Call-ID: 121212@10.0.0.1 809 Cseq: 1 NOTIFY 810 Event: Presence 811 Subscription-State: active; expires=3599 812 Contact: sip:presentity@server.domain.com 813 Content-Type: application/pidf+xml 814 Content-Length: ... 816 817 820 821 822 open 823 824 voice 825 tel:2224055555@domain.com 826 828 830 7.1.3 Subscriber Requests Notifications when Presentity's Status 831 Changes 833 The subscriber subscribes to the presentity, specifying in the filter 834 that it wants notifications only when the element has changed 835 to value 'open' 837 SUBSCRIBE request from the subscriber including filter: 839 SUBSCRIBE sip:presentity@domain.com 840 Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 841 To: 842 From: ;tag:12341111 843 Call-ID: 121212@10.0.0.1 844 Cseq: 1 SUBSCRIBE 845 Expires: 3600 846 Event: Presence 847 Contact: 848 Content-Type: application/simple-filter+xml 849 Content-Length: ... 851 852 853 854 855 857 858 859 860 861 /pidf:presence/pidf:tuple/pidf:status/pidf:basic 862 863 864 865 867 At some point during the subscription, a 2nd PIDF document is created 868 with both tuples having status of closed: 870 871 874 875 876 closed 877 878 im 879 im:presentity@domain.com 880 881 882 883 closed 884 885 voice 886 tel:2224055555@domain.com 887 888 890 A NOTIFY is not sent to the subscriber in this case. 892 Now, a 3rd PIDF document is created when IM status changes to OPEN: 894 895 898 899 900 open 901 902 im 903 im:presentity@domain.com 904 905 906 907 closed 908 909 voice 910 tel:2224055555@domain.com 911 912 914 Notification to the subscriber is sent in this case: 916 NOTIFY sip:watcher@client.domain.com SIP/2.0 917 Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 918 To: ;tag:12341111 919 From: ;tag:232321 920 Call-ID: 121212@10.0.0.1 921 Cseq: 1 NOTIFY 922 Event: Presence 923 Subscription-State: active; expires=3599 924 Contact: sip:presentity@server.domain.com 925 Content-Type: application/pidf+xml 926 Content-Length: ... 928 929 932 933 934 closed 935 936 im 937 im:presentity@domain.com 938 939 940 941 open 942 943 voice 944 tel:2224055555@domain.com 945 946 948 7.2 Watcher Information Specific Examples 950 The examples in this section use the winfo template-package with the 951 presence event package [10]. 953 Watcher information to a Presentity: 955 956 958 960 sip:watcherA@example.com" 965 sip:watcherB@example.com" 970 sip:watcherC@example.com" 975 sip:watcherD@domain.com" 980 981 983 7.2.1 Watcher Subscriber Makes Subscription to Get All the Information 984 about Active Watchers 986 SUBSCRIBE request from the presentity including the filter: 988 SUBSCRIBE sip:presentity@domain.com 989 Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 990 To: 991 From: ;tag:12341111 992 Call-ID: 121212@10.0.0.1 993 Cseq: 1 SUBSCRIBE 994 Expires: 3600 995 Event: Presence.winfo 996 Contact: sip:presentity@client.domain.com 997 Content-Type: application/simple-filter+xml 998 Content-Length: ... 1000 1001 1002 1003 1005 1006 1007 1008 1009 /wi:watcherinfo/wi:watcher-list[@package="presence"]/ 1010 wi:watcher[@status="active"] 1011 1012 1013 1014 1016 Notification to the subscriber: 1018 NOTIFY sip:presentity@client.domain.com SIP/2.0 1019 Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 1020 To: sip:presentity@domain.com;tag:12341111 1021 From: sip:presentity@domain.com;tag:232321 1022 Call-ID: 121212@10.0.0.1 1023 Cseq: 1 NOTIFY 1024 Contact: sip:presentity@server.domain.com 1025 Event: Presence.winfo 1027 Content-Type: application/watcherinfo+xml 1028 Content-Length: ... 1030 1031 1033 1035 sip:watcherA@example.com" 1040 sip:watcherD@domain.com" 1045 1046 1048 7.2.2 Watcher Subscriber Requests Information of Watchers with Specific 1049 Subscription Duration Conditions 1051 SUBSCRIBE request from the presentity including the filter: 1053 SUBSCRIBE sip:presentity@domain.com 1054 Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 1055 To: ;tag:12341111 1056 From: 1057 Call-ID: 121212@10.0.0.1 1058 Cseq: 1 SUBSCRIBE 1059 Expires: 0 1060 Event: Presence.winfo 1061 Contact: 1062 Content-Type: application/simple-filter+xml 1063 Content-Length: ... 1065 1066 1067 1068 1070 1071 1072 1073 1074 /wi:watcherinfo/wi:watcher-list[@package="presence"]/ 1075 wi:watcher[@duration-subscribed>500] 1076 1077 1078 1079 1081 Notification to the subscriber: 1083 NOTIFY sip:presentity@client.domain.com SIP/2.0 1084 Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 1085 To: sip:presentity@domain.com;tag:12341111 1086 From: sip:presentity@domain.com;tag:232321 1087 Call-ID: 121212@10.0.0.1 1088 Cseq: 1 NOTIFY 1089 Contact: sip:presentity@server.domain.com 1090 Event: Presence.winfo 1092 Content-Type: application/watcherinfo+xml 1093 Content-Length: ... 1095 1096 1098 1100 sip:watcherA@example.com" 1105 sip:watcherB@example.com" 1110 1111 1113 7.2.3 Watcher Subscriber Requests Specific Watcher Info On Specific 1114 Triggers 1116 This filter selects watcher information notifications [9] to be sent 1117 when the pending subscription status has changed from 'pending' to 1118 'terminated'. In the notification, only the watchers that have a 1119 status of 'terminated' and an event of 'rejected' are included. 1121 SUBSCRIBE request from the Watcher Subscriber including the filter: 1123 SUBSCRIBE sip:presentity@domain.com 1124 Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 1125 To: ;tag:12341111 1126 From: 1127 Call-ID: 121212@10.0.0.1 1128 Cseq: 1 SUBSCRIBE 1129 Expires: 0 1130 Event: Presence.winfo 1131 Contact: 1132 Content-Type: application/simple-filter+xml 1133 Content-Length: ... 1135 1136 1137 1138 1140 1141 1142 1143 1144 /wi:watcherinfo/wi:watcher-list[@package="presence"]/ 1145 wi:watcher[@status="terminated" and @event="rejected"] 1146 1147 1148 1149 1151 //@status 1152 1153 1154 1155 1157 At some point during the subscription, a 2nd Winfo document is 1158 created due to some change: 1160 1161 1163 1165 sip:watcherA@example.com" 1170 sip:watcherB@example.com" 1175 sip:watcherC@example.com" 1180 sip:watcherD@domain.com" 1185 1186 1188 Notification to the subscriber is created, taking into account the 1189 and elements: 1191 NOTIFY sip:presentity@client.domain.com SIP/2.0 1192 Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 1193 To: sip:presentity@domain.com;tag:12341111 1194 From: sip:presentity@domain.com;tag:232321 1195 Call-ID: 121212@10.0.0.1 1196 Cseq: 1 NOTIFY 1197 Contact: sip:presentity@server.domain.com 1198 Event: Presence.winfo 1200 Content-Type: application/watcherinfo+xml 1201 Content-Length: ... 1203 1204 1206 1208 sip:watcherB@example.com" 1213 sip:watcherC@example.com" 1218 1219 1221 8. Security Considerations 1223 The presence of filters in the body in a SIP message has a 1224 significant effect on the ways in which the request is handled at a 1225 server. As a result, it is especially important that messages 1226 containing this extension be authenticated and authorized. 1228 Processing of requests and looking up filters requires set operations 1229 and searches, which can require some amount of computation. This 1230 enables a DoS attack whereby a user can send requests with 1231 substantial numbers messages with large contents, in the hopes of 1232 overloading the server. To counter this, the server can establish a 1233 limit on the number of occurrences of the , , 1234 and elements allowed in the filters. A default limit of 40 1235 is RECOMMENDED, however, servers may raise or lower the limit 1236 depending upon their specific engineered capacity. 1238 Requests can reveal sensitive information about a UA's capabilities. 1240 If this information is sensitive, it SHOULD be encrypted using SIP 1241 S/MIME capabilities [6]. All package specific security measures MUST 1242 be followed. 1244 Propagating filters in SUBSCRIBE requests to foreign domains reveals 1245 sensitive information about a user's resource lists. It is therefore 1246 required that an RLS does not forward a filter if that filter is 1247 addressed to a resource that is under the administrative domain of 1248 the RLS, but is not on the resource list. Section 4.1 shows an 1249 example where such a scenario can occur. 1251 It is important to note that a flitered document located at a 1252 subscriber may project false reality. For example, if a subscriber 1253 asked to be notified when a resource has changed his presence state 1254 from closed to open but not from open to closed, then the subscriber 1255 may afterwards be under the false impression that the resource's 1256 presence state is open even long after the resource has changed it to 1257 closed. Therefore, subscribers need to be sure what they put in a 1258 filter, understand what they asked for and be prepared to be out of 1259 sync with the real state of a resource. 1261 9. IANA Considerations 1263 A new event-reason-value "badfilter" is defined to represent the 1264 event where the filter is not well formed and/or not accepted. No 1265 IANA registration is required for this value. 1267 10. Acknowledgements 1269 The authors would like to thank George Foti, Tim Moran, Sreenivas 1270 Addagatla, Juha Kalliokulju, Jari Urpalainen and Mary Barnes for 1271 their valuable input. 1273 11. References 1275 11.1 Normative References 1277 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1278 Levels", BCP 14, RFC 2119, March 1997. 1280 [2] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, 1281 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1282 Session Initiation Protocol", RFC 3261, June 2002. 1284 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1285 Notification", RFC 3265, June 2002. 1287 [4] Roach, A., "A Session Initiation Protocol (SIP) Event 1288 Notification Extension for Resource Lists", 1289 draft-ietf-simple-event-list-07.txt, December 2004. 1291 [5] Khartabil, H., "An Extensible Markup Language (XML) Based Format 1292 for Event Notification Filtering", 1293 draft-ietf-simple-filter-format-04.txt, January 2005. 1295 [6] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1296 2633, June 1999. 1298 11.2 Informative References 1300 [7] Sugano, H., "Presence Information Data Format", RFC 3863, 1301 Auguest 2004. 1303 [8] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions 1304 for Presence", RFC 3856, July 2004. 1306 [9] Rosenberg, J., "An Extensible Markup Language (XML) Based 1307 Format for Watcher Information", RFC 3858, July 2004. 1309 [10] Rosenberg, J., "A Watcher Information Event Template-Package 1310 for SIP", RFC 3857, July 2004. 1312 Authors' Addresses 1314 Hisham Khartabil 1315 Telio 1316 P.O. Box 1203 Vika 1317 Oslo 1318 Norway 1320 Phone: +47 2167 3544 1321 EMail: hisham.khartabil@telio.no 1323 Eva Leppanen 1324 Nokia 1325 P.O BOX 785 1326 Tampere 1327 Finland 1329 Phone: +358 7180 77066 1330 EMail: eva-maria.leppanen@nokia.com 1331 Mikko Lonnfors 1332 Nokia 1333 Itamerenkatu 00180 1334 Helsinki 1335 Finland 1337 Phone: + 358 50 4836402 1338 EMail: mikko.lonnfors@nokia.com 1340 Jose Costa-Requena 1341 Nokia 1342 P.O. Box 321 1343 FIN-00045 NOKIA GROUP 1344 FINLAND 1346 Phone: +358 71800 8000 1347 EMail: jose.costa-requena@nokia.com 1349 Intellectual Property Statement 1351 The IETF takes no position regarding the validity or scope of any 1352 Intellectual Property Rights or other rights that might be claimed to 1353 pertain to the implementation or use of the technology described in 1354 this document or the extent to which any license under such rights 1355 might or might not be available; nor does it represent that it has 1356 made any independent effort to identify any such rights. Information 1357 on the procedures with respect to rights in RFC documents can be 1358 found in BCP 78 and BCP 79. 1360 Copies of IPR disclosures made to the IETF Secretariat and any 1361 assurances of licenses to be made available, or the result of an 1362 attempt made to obtain a general license or permission for the use of 1363 such proprietary rights by implementers or users of this 1364 specification can be obtained from the IETF on-line IPR repository at 1365 http://www.ietf.org/ipr. 1367 The IETF invites any interested party to bring to its attention any 1368 copyrights, patents or patent applications, or other proprietary 1369 rights that may cover technology that may be required to implement 1370 this standard. Please address the information to the IETF at 1371 ietf-ipr@ietf.org. 1373 Disclaimer of Validity 1375 This document and the information contained herein are provided on an 1376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1378 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1379 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1380 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1383 Copyright Statement 1385 Copyright (C) The Internet Society (2005). This document is subject 1386 to the rights, licenses and restrictions contained in BCP 78, and 1387 except as set forth therein, the authors retain all their rights. 1389 Acknowledgment 1391 Funding for the RFC Editor function is currently provided by the 1392 Internet Society.