idnits 2.17.1 draft-ietf-simple-pres-filter-reqs-02.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 194 has weird spacing: '...ased on names...' == Line 234 has weird spacing: '...ltering to...' == Line 238 has weird spacing: '...ltering to in...' == 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 (August 14, 2003) is 7555 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) -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-03) exists of draft-kiss-simple-presence-wireless-reqs-02 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-03 == Outdated reference: A later version (-02) exists of draft-lonnfors-simple-partial-notify-01 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG H. Khartabil 3 Internet-Draft E. Leppanen 4 Expires: February 12, 2004 Nokia 5 T. Moran 6 August 14, 2003 8 Requirements for Presence Specific Event Notification Filtering 9 draft-ietf-simple-pres-filter-reqs-02 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 other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 12, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document defines a set of structured requirements whereby a 40 presence information subscriber may select specific information to be 41 received in the presence information notification sent by the 42 notifier. The purpose is to limit the content and frequency of 43 notifications so that only essential information on a need basis is 44 delivered by the server. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Requirements for Specification of Filters . . . . . . . . . 4 51 3.1 Package Identification . . . . . . . . . . . . . . . . . . . 4 52 3.2 Target URI . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.3 Notification Triggering . . . . . . . . . . . . . . . . . . 4 54 3.4 Notification Content . . . . . . . . . . . . . . . . . . . . 5 55 4. Requirements for Uploading Filter Criteria (Operational 56 Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1 Subscription . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1.1 Maintaining a Filter . . . . . . . . . . . . . . . . . . . . 5 59 4.1.2 Changing a Filter . . . . . . . . . . . . . . . . . . . . . 6 60 4.2 Server Support For Filters . . . . . . . . . . . . . . . . . 6 61 5. Interaction with Other Features . . . . . . . . . . . . . . 6 62 5.1 Resource Lists . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2 Partial Notifications . . . . . . . . . . . . . . . . . . . 7 64 5.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 66 7. Example Applications for Notification Filtering . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Main changes from version 01 . . . . . . . . . . . . . . . . 8 69 10. Main changes from version 00 . . . . . . . . . . . . . . . . 9 70 References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . 11 74 1. Introduction 76 SIP event notification is described in [6]. It defines a general 77 framework for subscriptions and notifications for SIP event packages. 78 Concrete applications of the general event framework to a specific 79 group of events are described in [5] (user presence) and [7] (watcher 80 information). 82 The presence information refers to a set of presence attributes 83 describing the availability and willingness of the user (presentity) 84 for communication. The user makes his presence information available 85 for other users (watchers). 87 As the inherent usage of event packages grows, the client needs some 88 mechanisms for controlling the event notifications at the source. 89 Evidence of this need is found in [4]. 91 The document describing the Presence event package [5] mentions the 92 possibility for filtering. Accordingly, the SUBSCRIBE request may 93 contain a body for filtering the presence information subscription. 94 However, the definition of filtering was considered out of scope was 95 left as future work. 97 These mechanisms are expected to be particularly valuable to users of 98 wireless devices. The characteristics of these devices typically 99 include low bandwidth, low data processing capabilities, small 100 display and limited battery power. Such devices can benefit from the 101 ability to filter the amount of information generated at the source 102 of the event notifications. 104 However, it is expected that the control mechanisms for event 105 notifications add value for all users irrespectively of their device 106 or network access characteristics. 108 Section 3 and Section 4 of this draft propose a set of requirements 109 whereby a client may specify which notifications it is interested in. 110 That is, a means to specify filtering rules to be executed by the 111 server. Section 7 provides a few example applications of notification 112 filtering. 114 2. Conventions 116 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 117 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 118 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 119 and indicate requirement levels for compliant implementations. 121 3. Requirements for Specification of Filters 123 The following requirements relate to the creation of filter criteria. 125 3.1 Package Identification 127 REQ xx: It MUST be possible for the creator of the filter to specify 128 the package the filter applies to. 130 3.2 Target URI 132 REQ xx: It MUST be possible for the watcher to indicate, in the 133 filter, the target presentity whose presence information a certain 134 filter is applied to. 136 REQ xx: It MUST be possible for the watcher to indicate, in the 137 filter criteria, the target presentity list whose presence 138 information a certain filter is applied to. 140 REQ xx: It MUST be possible for the watcher to indicate, in the 141 filter criteria, the target presentity sub-list whose presence 142 information a certain filter is applied to. 144 REQ xx: It MUST be possible for the watcher to indicate, in the 145 filter criteria, the target domain that contains presentities whose 146 presence information a certain filter is applied to. 148 3.3 Notification Triggering 150 This chapter presents requirements for specifying the triggering 151 conditions that result in notifications to be sent to the client. 153 REQ xx: It MUST NOT be possible to break any server side policy 154 constraints when applying the triggering conditions. For example, it 155 must not be possible for a watcher to request a notification when the 156 element value of a certain presentity has changed from OPEN 157 to CLOSED when there is a local server policy constraining the 158 delivery of any tuple with a element value of CLOSED. 160 REQ xx: The triggering conditions MUST be based on the presence 161 information. For example, the change of value of the 162 element. 164 REQ xx: It MUST be possible to specify logical expressions based on 165 the value of elements defined in the package for the purpose of 166 triggering. This covers expressions (tests) related to the change of 167 an element's value, and reaching a certain value of an element. 169 REQ xx: It MUST be possible to construct one filter that combine 170 multiple triggering conditions. 172 3.4 Notification Content 174 This chapter presents requirements for specifying the filter for 175 choosing content to be sent in the notifications. 177 REQ xx: It MUST NOT be possible to break any server side policy 178 constraints when applying the content filter. For example, it must 179 not be possible for a watcher to request a notification to contain 180 the element of a certain presentity when there is a local 181 server policy constraining the delivery of the element. 183 REQ xx: It MUST be possible for the watcher to specify the presence 184 information elements (XML elements and/or attributes) in [2] to be 185 delivered in the notification. 187 REQ xx: It MUST be possible for the watcher to specify presence 188 information in any extension to PIDF to be delivered in the 189 notifications, based on XML elements and/or attributes. See for 190 example [3]. 192 REQ xx: It MUST be possible for the watcher to specify presence 193 information in any extension to be delivered in the notifications, 194 based on namespaces. 196 REQ xx: It MUST be possible to construct one filter that combine 197 multiple elements and attributes to be included the notifications. 199 4. Requirements for Uploading Filter Criteria (Operational Rules) 201 REQ xx: It MUST be possible for the watcher to upload filter criteria 202 to the server (notifier) and know the status - accepted or rejected. 204 4.1 Subscription 206 REQ xx: It MUST be possible to place a filter in the body of the 207 SUBSCRIBE request. 209 REQ xx: It MAY be possible to deliver a filter to a server using 210 other means. For example, it may be possible for the filter to be 211 (permanently) stored in the server. 213 4.1.1 Maintaining a Filter 215 REQ xx: The watcher MUST NOT be required to re-set a filter at any 216 time during the subscription, once the filter has been set. 218 REQ xx: The watcher SHOULD NOT be required to re-set a filter when 219 refreshing a subscription, once the filter has been set. 221 REQ xx: Maintaining a filter across subscription refreshes SHOULD be 222 bandwidth efficient. 224 4.1.2 Changing a Filter 226 REQ xx: It MUST be possible to change the filter during a 227 subscription. 229 REQ xx: It MUST be possible for the watcher to remove a set filter, 230 reverting back to a server defined default. 232 4.2 Server Support For Filters 234 REQ xx: It MUST be possible for a server not supporting filtering to 235 inform the watcher of the failure. 237 REQ xx: It MUST be possible for a server not understanding a 238 filtering to inform the watcher of the failure. 240 REQ xx: It MUST be possible for a server not accepting a filter to 241 inform the watcher of the reasons for not accepting the filter. 243 REQ xx: It MUST be possible for a server to terminate a subscription 244 based on a filter becoming invalid due to sever local policy change. 245 (How do I word this in a requirement text?) 247 5. Interaction with Other Features 249 5.1 Resource Lists 251 REQ xx: It MUST be possible to support filtering for subscriptions to 252 resource lists [8]. 254 REQ xx: It MUST be possible for a watcher to specify filter criteria 255 for a resource list and/or any nested sub list of the resource list. 257 REQ xx: It MUST be possible for a watcher to specify different filter 258 for any individual member of a resource list in a resource list 259 subscription. 261 REQ xx: It MUST be possible for a watcher to specify different filter 262 criteria for individual members of any of nested sub lists of a 263 resource list in a resource list subscription. Any of the nested sub 264 lists may be located in a different domain from the parent list. 266 REQ xx: It MUST be possible for each watcher to define own filter 267 criteria within resource list subscription if there are several 268 simultaneous watchers using the same list. 270 5.2 Partial Notifications 272 REQ xx: It MUST be possible to use filtering along with the partial 273 notification [9] within the same subscription. 275 5.3 Authorization 277 REQ xx: Authorization SHOULD occur irrespective of the filtering. 279 6. Security Considerations 281 Security requirements specified for [5] also applies to the presence 282 filtering. Additional security considerations related to the presence 283 filtering are described as follows. 285 REQ xx: It SHOULD be possible for the server to hide the fact that a 286 filter was not acceptable. 288 REQ xx: The presence of filter criteria in the body in a SIP message 289 has a significant effect on the way in which the request is handled 290 at a server. As a result, it is especially important that messages 291 containing filter criteria are authenticated and authorized. 293 REQ xx: Modification to the Filter Criteria by an intermediary could 294 also result in the watcher either not receiving notifications of 295 presence information they are interested in or receiving a very large 296 presence document. Therefore the filter criteria SHOULD be integrity 297 protected between those nodes that are authorised to modify it (e.g., 298 the resource list servers). 300 REQ xx: Processing of requests and looking up filter criteria 301 requires some amount of computation. This enables a DoS attack 302 whereby a user can send requests with substantial numbers messages 303 with large contents, in the hopes of overloading the server. To 304 prevent this the number of filter criteria allowed in a request 305 should be limited. 307 REQ xx: Requests containing filter criteria can reveal sensitive 308 information about a UA's capabilities. If this information is 309 sensitive, it SHOULD be encrypted using methods that allow it to be 310 read by those nodes that need to do so (e.g., the resource list 311 servers). 313 REQ xx: The resource list servers SHOULD convey only those parts of 314 filter information targeted to the same destination as the fanned out 315 individual subscriptions, if the filter information is conveyed 316 further within the subscription. 318 7. Example Applications for Notification Filtering 320 1. A watcher wishes to get to know presentity's availability and 321 willingness for messaging (e.g. IM and MMS). 323 2. A watcher is interested in getting information about the 324 communication means and contact addresses the presentity is 325 currently available for communication. 327 3. A watcher requires a notification if the state of a buddy has 328 changed to 'open'. 330 4. A watcher only wants to be notified when the presentity's 331 location is Dallas or Fort Worth. The notification should include 332 the vehicle license, driver name, and city. 334 5. A Basic location tracking service requires notification when the 335 presentity's cell id changes. The notification should include the 336 cell id. 338 6. A watcher is interested in being notified when a presentity gains 339 a new communication capability such as a new networked 340 multi-player game. 342 8. Acknowledgements 344 The authors would like to thank Andrew Allen, Sreenivas Addagatla, 345 Mikko Lonnfors, Juha Kalliokulju, Aki Niemi, Jose Costa-Requena and 346 Markus Isomaki for their valuable input. 348 9. Main changes from version 01 350 o "Overview of Operation" section removed . 352 o "Common Syntax" section removed. 354 o "Discovery of Items" section removed as agreed in IETF 57 356 o Added requirement about filtering using namespaces. 358 o Added requirement about filtering using domain name. 360 o Clarified and split larger requirements into smaller more concrete 361 requirements. 363 o Updated the Authors of this ID 365 10. Main changes from version 00 367 o Overview of functionality chapter added. 369 o More specific requirements for supporting filtering with the 370 resource lists, and nested lists. 372 o Interaction with other features chapter added. 374 o More specific requirements to support getting information about 375 the structure of presence document, and changes in it. 377 o Several filter specific additions to security considerations. 379 o Several editorial changes, e.g., reference and terminology 380 updates. 382 References 384 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 385 Levels", BCP 14, RFC 2119, March 1997. 387 [2] Sugano, H., "CPIM Presence Information Data Format", 388 draft-ietf-impp-cpim-pidf-08.txt, May 2003. 390 [3] Schulzrinne, H., "RPIDS -- Rich Presence Information Data Format 391 for Presence Based on the Session Initiation Protocol (SIP)", 392 draft-schulzrinne-simple-rpids-01.txt, February 2003. 394 [4] Kiss, K., "Requirements for Presence Service based on 3GPP 395 specifications and wireless environment characteristics", 396 draft-kiss-simple-presence-wireless-reqs-02, February 2003. 398 [5] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for 399 Presence", draft-ietf-simple-presence-10.txt, January 2003. 401 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 402 Notification", RFC 3265, June 2002. 404 [7] Rosenberg, J., "A Watcher Information Event Template-Package for 405 the Session Initiation Protocol (SIP)", 406 draft-ietf-simple-winfo-package-05.txt, January 2003. 408 [8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 409 Notification Extension for Resource Lists", 410 draft-ietf-simple-event-list-03.txt, May 2003. 412 [9] Lonnfors, M., "Partial Notification of Presence Information", 413 draft-lonnfors-simple-partial-notify-01.txt, May 2003. 415 Authors' Addresses 417 Hisham Khartabil 418 Nokia 419 P.O BOX 321 420 Helsinki 421 Finland 423 Phone: +358 7180 76161 424 EMail: hisham.khartabil@nokia.com 426 Eva Leppanen 427 Nokia 428 P.O BOX 785 429 Tampere 430 Finland 432 Phone: +358 7180 77066 433 EMail: eva-maria.leppanen@nokia.com 435 Tim Moran 436 2800 Britt Drive 437 Argyle, Texas 76226 438 USA 440 Phone: +1 972 849 8821 441 EMail: tl_moran@att.net 443 Intellectual Property Statement 445 The IETF takes no position regarding the validity or scope of any 446 intellectual property or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; neither does it represent that it 450 has made any effort to identify any such rights. Information on the 451 IETF's procedures with respect to rights in standards-track and 452 standards-related documentation can be found in BCP-11. Copies of 453 claims of rights made available for publication and any assurances of 454 licenses to be made available, or the result of an attempt made to 455 obtain a general license or permission for the use of such 456 proprietary rights by implementors or users of this specification can 457 be obtained from the IETF Secretariat. 459 The IETF invites any interested party to bring to its attention any 460 copyrights, patents or patent applications, or other proprietary 461 rights which may cover technology that may be required to practice 462 this standard. Please address the information to the IETF Executive 463 Director. 465 Full Copyright Statement 467 Copyright (C) The Internet Society (2003). All Rights Reserved. 469 This document and translations of it may be copied and furnished to 470 others, and derivative works that comment on or otherwise explain it 471 or assist in its implementation may be prepared, copied, published 472 and distributed, in whole or in part, without restriction of any 473 kind, provided that the above copyright notice and this paragraph are 474 included on all such copies and derivative works. However, this 475 document itself may not be modified in any way, such as by removing 476 the copyright notice or references to the Internet Society or other 477 Internet organizations, except as needed for the purpose of 478 developing Internet standards in which case the procedures for 479 copyrights defined in the Internet Standards process must be 480 followed, or as required to translate it into languages other than 481 English. 483 The limited permissions granted above are perpetual and will not be 484 revoked by the Internet Society or its successors or assignees. 486 This document and the information contained herein is provided on an 487 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 488 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 489 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 490 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 491 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 493 Acknowledgement 495 Funding for the RFC Editor function is currently provided by the 496 Internet Society.