idnits 2.17.1 draft-ietf-simple-event-filter-funct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 64 characters in excess of 72. ** There are 19 instances of lines with control characters in the document. == 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 381 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 (February 3, 2004) is 7386 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) == Unused Reference: '14' is defined on line 1074, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '5') (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 -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-08) exists of draft-niemi-sipping-event-throttle-00 == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE H. Khartabil 3 Internet-Draft E. Leppanen 4 Expires: August 3, 2004 M. Lonnfors 5 J. Costa-Requena 6 Nokia 7 February 3, 2004 9 Functional Description of Event Notification Filtering 10 draft-ietf-simple-event-filter-funct-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as 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 http:// 27 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 August 3, 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 a 43 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Client Operation . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1 Transport Mechanism . . . . . . . . . . . . . . . . . . . . 4 61 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3 Subscriber Generating SUBSCRIBE Requests . . . . . . . . . . 4 63 3.3.1 Structure of a Filter . . . . . . . . . . . . . . . . . . . 4 64 3.3.2 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . . 5 65 3.3.3 Changing Filters within a Dialog . . . . . . . . . . . . . . 5 66 3.3.4 Subscriber Interpreting SIP responses . . . . . . . . . . . 5 67 3.4 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 6 68 4. Resource List Server Behaviour . . . . . . . . . . . . . . . 6 69 4.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . . 6 70 5. Server Operation . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2 Notifier Processing SUBSCRIBE Requests . . . . . . . . . . . 7 73 5.2.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . . 7 74 5.3 Notifier Generating NOTIFY Requests . . . . . . . . . . . . 8 75 5.3.1 Generation of NOTIFY Contents . . . . . . . . . . . . . . . 8 76 5.3.2 Handling of Notification Triggering Rules . . . . . . . . . 9 77 5.4 Handling Abnormal Cases . . . . . . . . . . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 79 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7.1 Presence Specific Examples . . . . . . . . . . . . . . . . . 10 81 7.1.1 Subscriber Requests Messaging Related Information . . . . . 11 82 7.1.2 Subscriber Fetches Information about "Open" 83 Communication Means . . . . . . . . . . . . . . . . . . . . 12 84 7.1.3 Subscriber Requests Notifications when Presentity's 85 Status Changes . . . . . . . . . . . . . . . . . . . . . . . 14 86 7.2 Watcher Information Specific Examples . . . . . . . . . . . 16 87 7.2.1 Watcher Subscriber Makes Subscription to Get All the 88 Information about Active Watchers . . . . . . . . . . . . . 17 89 7.2.2 Watcher Subscriber Requests Information of Watchers with 90 Specific Subscription Duration Conditions . . . . . . . . . 18 91 7.2.3 Watcher Subscriber Requests Specific Watcher Info On 92 Specific Triggers . . . . . . . . . . . . . . . . . . . . . 20 93 8. Security Considerations . . . . . . . . . . . . . . . . . . 22 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 95 References . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 97 Intellectual Property and Copyright Statements . . . . . . . 25 99 1. Conventions 101 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 102 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 103 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 104 and indicate requirement levels for compliant implementations. 106 2. Introduction 108 SIP event notification is described in [5]. It defines a general 109 framework for sending subscriptions and receiving notifications in 110 SIP based systems. It introduces the concept of event packages, which 111 are concrete applications of the general event framework to a 112 specific usage of events. 114 Filtering is a mechanism for controlling the content of event 115 notifications. Additionally, the subscriber may specify the rules for 116 when a notification should be sent to it. Requirements for such 117 mechanisms are defined in [10] and [11]. 119 The filtering mechanism is expected to be particularly valuable to 120 users of mobile wireless access devices. The characteristics of the 121 devices typically include high latency, low bandwidth, low data 122 processing capabilities, small display, and limited battery power. 123 Such devices can benefit from the ability to filter the amount of 124 information generated at the source of the event notification. 126 It is stated in [5] that the notifier may send a NOTIFY at any time, 127 but typically it is sent when the state of the resource changes. It 128 also states that the notifications would contain the complete and 129 current state of the resource authorized for a certain subscriber to 130 see. The format of such resource state information is package 131 specific. In this memo, we assume that the NOTIFY for any package 132 contains an XML document. 134 There is a separate approach for the rate limiting of SIP event 135 notifications, namely the throttling mechanism [12]. This throttling 136 mechanism allows the subscriber to specify a maximum rate at which 137 event notifications are generated by a single notifier. The solution 138 for such requirements is out of scope for this document. 140 This document presents a mechanism for filtering whereby a subscriber 141 describes its preference of when notifications are to be sent to it 142 and what they are to contain. It also describes how the notifier 143 functions when generating notifications by taking into account 144 filters and default functionality of the package/service. 146 The XML format for defining the filter is described in [9]. 148 3. Client Operation 150 3.1 Transport Mechanism 152 Transportation of the filter to the server is achieved by inserting 153 the XML document, as defined in [9], in the body of the SUBSCRIBE 154 request. Alternatively, the XML document can be uploaded to the 155 server using means outside the scope of this document. 157 3.2 SUBSCRIBE Bodies 159 SIP entities compliant with this specification MUST support the 160 content type 'application/simple-filter+xml'. 162 3.3 Subscriber Generating SUBSCRIBE Requests 164 This section presents additional functionality required from the 165 subscriber when filters are used in the bodies of the SUBSCRIBE 166 requests. Normal operations of services, e.g., as defined in [4], [8] 167 and [6] are otherwise followed. 169 As defined in [5], the SUBSCRIBE message MAY contain a body. This 170 body would serve the purpose of carrying filtering information. 171 Honouring those filters is at the discretion of the notifier and 172 might depend on local policies. 174 No content in the body of a SUBSCRIBE indicates to the notifier that 175 no filter is being requested so that the notifier is instructed to 176 send all the NOTIFY requests using the notifier's own or service 177 specific policy. Note that e.g. in the list case [6] the filter might 178 have been uploaded to the server beforehand (by means outside the 179 scope of this document). 181 If the body of the SUBSCRIBE includes the filter, the body MUST be of 182 the MIME-Type 'application/simple-filter+xml'. 184 3.3.1 Structure of a Filter 186 Multiple filters MAY be included in one SUBSCRIBE. This is achieved 187 by including multiple elements in the filter [9]. Each 188 element may include a URI attribute. 190 A SUBSCRIBE request destined to a list URI [6] MAY include multiple 191 filters specific to individual resources. This is achieved by 192 including multiple elements with different URIs of resources 193 in each of those elements. This resource specific filter overrides 194 any list specific filter, if any. The list specific filter may or may 195 not include a URI. 197 3.3.2 Request-URI vs. Filter URI 199 The URI in the filter defines the target resource, e.g. in the 200 Presence service case; it is the presentity's presence information to 201 which the filter is applied. The subscriber MAY choose to leave the 202 URI in the filter undefined. If the URI is not defined within the 203 filter, the filter applies to the resource identified in the 204 Request-URI. Similarly, the subscriber MAY define a filter URI. If 205 the Request-URI is a list URI [6], the filter URI MUST be the list 206 URI, a sub-list URI or resource who's URI is one of the URIs that 207 result from a lookup, by an RLS, on the Request-URI. If not, the 208 filter may be ignored or may be rejected. 210 The URI in the filter may also carry a domain. In this case, the 211 filter applies to resources in that domain. This can be used when a 212 subscription is for a resource that is an event list with many 213 resources from differing domains. 215 3.3.3 Changing Filters within a Dialog 217 The client MAY reset or change the filter by re-issuing a new 218 SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the 219 exiting dialog that does not contain a filter is assumed to maintain 220 existing filters. This means that filters are persistent and are only 221 explicitly removed. 223 A client requiring removal of a filter may do so by using the 224 'removed="true"' attribute as defined in [9]. 226 In the case the URI in the filter is that of a list, a client may 227 override the existing filter with a filter for an individual 228 resource, that is part of the list subscribed to earlier, by issuing 229 a new SUBSCRIBE within the existing dialog and including a filter 230 specific for that individual resource. The new filter need not 231 include the original filter since a filter is only removed in the 232 manner indicated above. 234 3.3.4 Subscriber Interpreting SIP responses 236 The SUBSCRIBE request will be confirmed with a final response. A 237 200-class responses indicate that the subscription has been accepted, 238 and that a NOTIFY will be sent immediately. A "200" response 239 indicates that the subscription has been accepted and the filter is 240 accepted. A "202" response merely indicates that the subscription has 241 been understood, the content type has been accepted, and that 242 authorization may or may not have been granted. A "202" response also 243 indicates that the filter has not been accepted yet. The acceptance 244 of the filter MAY arrive in a subsequent NOTIFY. 246 A non-200 class final responses indicate that no subscription or 247 dialog has been created, and no subsequent NOTIFY message will be 248 sent. All non-200 class final responses have the same meanings and 249 handling as described in [3] and [5]. 251 Specifically, a "415" response indicates that the MIME type 252 'application/simple-filter+xml' is not understood by the notifier. A 253 "488" response indicates that the content type (filter) is understood 254 but some aspects of it were either not understood or not accepted. 256 3.4 Subscriber Processing of NOTIFY Requests 258 If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that 259 follows MAY contain a body that describes the present state of the 260 resource after the filters have been applied. 262 If the NOTIFY indicates that a subscription has been terminated [5], 263 the subscription is assumed to be terminated. Behaviour in such 264 events is also described in [5]. 266 If the subscription is indicated as active, NOTIFY requests are 267 handled as described in package specific documents and [5]. 269 4. Resource List Server Behaviour 271 The Resource List Server is defined in [6]. This section describes 272 how such entity behaves in the presence of a filter in a subscription 273 to a list. 275 4.1 Request-URI vs. Filter URI 277 If the URI is not defined within the filter, the filter applies to 278 the resource identified in the Request-URI. 280 If no URI is indicated by the filter, the filter applies to all the 281 notifications that the RLS issues. If the URI indicated by the filter 282 is a list URI, the filter applies to all the notifications that the 283 RLS issues. 285 If the URI indicated by the filter is for one resource who's URI is 286 one of the URIs that result from a lookup, by the RLS, on the 287 Request-URI, the filter for that particular resource is extracted and 288 propagated in the SUBSCRIBE request sent to that resource. (It is 289 possible to have more than one filter in a SUBSCRIBE body, and 290 therefore a filter specific to a resource MUST be extracted and only 291 that is propagated. For example, if the Request-URI in a SUBSCRIBE 292 has the value "sip:mybuddies@mydomain.com" where 293 "bob@otherdomain.com" is a resource belonging to that list, and the 294 URI in a filter is "sip:bob@otherdomain.com", the filter specific for 295 Bob are extracted and placed in the body of the SUBSCRIBE sent to 296 "bob@otherdomain.com"). 298 If the URI indicated by the filter is for one resource who's URI is 299 NOT one of the URIs that result from a lookup, by the RLS, on the 300 Request-URI, the filter is propagated to all the fanned out 301 subscriptions. This is to accommodate the scenario where the 302 subscriber knows that there are sub-lists in the event list that the 303 original subscription was sent to, and the subscriber wishes to set a 304 filter for a resource in that sub-list. 306 The URI in the filter may carry a domain. In this case, the filter 307 applies to resources in that domain. The RLS MUST NOT apply filters 308 to any notifications it sends, but instead MUST forward the filter 309 with all fanned out subscriptions to the notifiers. 311 5. Server Operation 313 5.1 NOTIFY Bodies 315 SIP entities compliant with this specification MUST support 316 content-type 'application/simple-filter+xml'. 318 5.2 Notifier Processing SUBSCRIBE Requests 320 This section presents addition functionality required from the 321 notifier when filters are used in the bodies of the SUBSCRIBE 322 requests. Normal package specific functionality are otherwise 323 followed. 325 The notifier will examine the content type header and will return a 326 415 response if it does not understand the content type 'application/ 327 simple-filter+xml'. 329 A 200-class responses indicate that the subscription has been 330 accepted, and the NOTIFY will be sent immediately. A "200" response 331 indicates that the subscription has been accepted, the user is 332 authorized and the filter is accepted. A "202" response merely 333 indicates that the subscription has been understood, but the 334 authorization may or may not have been granted. A "202" response also 335 indicates that the filters have not been accepted yet. The acceptance 336 of the filters MAY arrive in a subsequent NOTIFY. 338 Procedures described in section Section 5.4 are followed if an error 339 is encountered. 341 5.2.1 Request-URI vs. Filter URI 343 The subscriber may have chosen to leave the URI in the filter 344 undefined. If the URI is not defined within the filter, the filter 345 applies to the resource identified in the Request-URI. 347 Similarly, the subscriber may have chosen to include a URI in the 348 filter. In this case, the filter applies to all notifications send 349 for this subscription. If the Request-URI and the URI in the filter 350 mismatch, the filter may be ignored or may be rejected. 352 The URI in the filter may carry a domain. In this case, the filter 353 applies to resources in that domain. The notifier MUST NOT apply 354 filters to any notifications it sends if the domain is not that of 355 its own, and MUST ignore it. Notifiers belonging to domain MUST apply 356 the filter to all notifications sent, unless policy dictates 357 otherwise. 359 5.3 Notifier Generating NOTIFY Requests 361 Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD 362 retain the filter as long as the subscription persists. The filter 363 MAY be incorporated within an existing subscription (in an active 364 dialog) by sending a re-SUBSCRIBE that includes the filter in the 365 body. 367 If the response sent to the SUBSCRIBE was the 202 and the 202 was 368 chosen because the filter could not be accepted that time, the NOTIFY 369 MAY be used to terminate the subscription if the filter was found 370 unacceptable. 372 As described in [5], the NOTIFY message MAY contain a body that 373 describes the state of the resource. This body is in one of the 374 formats listed in the Accept header of the SUBSCRIBE, or the package 375 specific default if the Accept header is omitted. 377 5.3.1 Generation of NOTIFY Contents 379 If the NOTIFY being sent is the immediate one sent after a 2xx 380 response to the original SUBSCRIBE, its contents MUST be populated 381 according to the filter. If applying the filter results in not 382 sending a NOTIFY, the NOTIFY MUST be sent with empty contents. A 383 notifier may also choose not to obey the filter in the first NOTIFY 384 and instead send the configured value authorised for that subscriber 385 set by the notifier using means outside the scope of this document). 387 The input to the content filter is a package specific XML document, 388 e.g. [2] and [7] derived according to the package specific 389 specifications, ([4] and [8]). 391 The content is filtered according to the expressions in the 392 element of the filter. The expression indicates the delivered XML 393 elements and/or attributes. Prefixes of the namespaces of the items 394 of the XML document to be filtered must be expanded before applying 395 the filter to the items. 397 The expression directly states the XML elements and attributes to be 398 delivered in the NOTIFY, along with their values. In addition to the 399 selected contents also the namespaces of all the selected items are 400 included in the NOTIFY. The XML elements and/or attributes indicated 401 by the expression in the element must be items that the 402 subscriber is authorised to see. If not, the notifier policy dictates 403 the behaviour of the notifier (notifier can either ignore the filter, 404 parts of the filter, or reject the filter completely). Implementers 405 need to carefully consider such an implementation decision; the 406 subscriber may not be aware of the authorised contents and therefore 407 most likely will include a filter requesting unauthorised contents. 408 It is therefore RECOMMENDED that notifiers just ignores the parts of 409 the filter where it is requesting unauthorised info. I.e. The filter 410 in the element where the unauthorised contents are requested 411 is ignored. If polite blocking is used by the notifier, the notifier 412 may choose to ignore the filter, by choosing to deliver notifications 413 containing bogus information in the unauthorised elements or 414 attributes. 416 The resultant XML document MUST be well formed and valid according to 417 the XML schema. This means that all mandatory elements and attributes 418 along with their values MUST be included in the XML document 419 regardless of the expression. In other words, if the results of 420 applying a filter on an XML document is a non-valid XML document, the 421 notifier MUST add elements and attributes, along with their values, 422 from the original XML document into the newly formulated one in order 423 for it to be a valid one. This situation can occur if the notifier 424 did not closely examine the filter before accepting it 426 5.3.2 Handling of Notification Triggering Rules 428 There can be several elements inside one element. 429 If the criteria for any of the elements are satisfied, a 430 NOTIFY SHOULD be generated. 432 The items (XML elements and/or attributes) indicated by the 433 expression in the element, element or 434 element must be items that the subscriber is authorised to access. If 435 not, the notifier policy dictates the behaviour of the notifier 436 (notifier can either ignore the filter, parts of the filter, or 437 reject the filter completely). 439 5.4 Handling Abnormal Cases 441 In case of an invalid filter definition where the XML document of the 442 filter is not aligned with the XML schema of the filter format[9], 443 the notifier rejects the SUBSCRIBE request with a "488" response. A 444 warning header in the response may give better indication why the 445 filters were not accepted. If the subscription was accepted with a 446 "202" response but the invalid filter was discovered after that, a 447 NOTIFY with a subscription-state of value 'terminated' is sent. An 448 event-reason-value "badfilter", introduced here, of subexp-params [5] 449 MAY be included. 451 In case of an erroneous expression in the filter definition the 452 notifier either ignores the filter definition or terminates the 453 subscription. 455 If a or element is empty, the notifier proceeds as 456 if the element did not exist. 458 6. IANA Considerations 460 A new event-reason-value "badfilter" is defined to represent the 461 event where the filter is not well formed and/or not accepted. 463 OPEN ISSUE: IANA registration template must be added later. [13] 465 7. Examples 467 The following chapters include filtering examples for Presence and 468 Watcher Information. The format of filter is according to [9]. 470 7.1 Presence Specific Examples 472 This chapter describes three use cases where the presence information 473 filtering solution is utilised [4]. In the first use case the watcher 474 is interested in getting messaging specific information of a certain 475 presentity. In the second use case the watcher is interested in 476 getting information about the communication means and contact 477 addresses the presentity is currently available for communication on. 478 The third case shows how a presentity can request triggers to receive 479 notifications 481 Below is the Presentity's presence information in PIDF [2]. It 482 includes two tuples: one for the instant messaging and another for 483 the voice related information. 485 486 489 490 491 closed 492 493 im 494 im:presentity@domain.com 495 496 497 498 open 499 500 voice 501 tel:2224055555@domain.com 502 503 505 7.1.1 Subscriber Requests Messaging Related Information 507 The subscriber initiates a subscription to the presentity's messaging 508 (MMS, IM and SMS) related presence information. The subscription 509 includes the content limiting filter. 511 The filtered content is indicated with an expression. This expression 512 selects the element and all the parent elements (this means 513 the status, tuple and its root element), the element and the 514 element. The filter is: elements that have values 515 beginning with "MMS", "SMS" or "IM". 517 In this case, the notification includes the contents of the tuple 518 that has the value "IM" in its