idnits 2.17.1 draft-avasarala-sipping-comm-div-notification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (December 20, 2008) is 5604 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3427 (ref. '3') (Obsoleted by RFC 5727) ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING R. Avasarala 3 Internet-Draft S. Saha 4 Intended status: Informational Motorola Inc 5 Expires: June 23, 2009 J. Bakker 6 Research In Motion Corporation 7 December 20, 2008 9 A Session Initiation Protocol (SIP) Event Package for Communication 10 Diversion Information in support of the Communication Diversion (CDIV) 11 Notification (CDIVN) CDIV service 12 draft-avasarala-sipping-comm-div-notification-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 23, 2009. 37 Copyright Notice 39 Copyright (c) 2008 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and 52 in particular the Communication Diversion (CDIV) using IP Multimedia 53 (IM) core Network (CN) subsystem supplementary service. As part of 54 CDIV, a (SIP) Event Notification Framework-based mechanism is used 55 for notifying Users about diversions (re-directions or forwarding) of 56 their incoming communication sessions. A new event package is 57 proposed for allowing users to subscribe for and receive such 58 notifications. Users have further capability to define filters 59 controlling the selection, rate and content of such notifications. 60 This SIP event package is applicable to the IMS and may not be 61 applicable to the general Internet. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 68 4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 6 69 4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7 74 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7 75 6.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 8 76 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 8 77 6.5. Notify bodies . . . . . . . . . . . . . . . . . . . . . . 8 78 6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 9 79 6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 9 80 6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 9 81 6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 9 82 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 10 83 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 10 84 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 10 85 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10 86 6.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 11 88 7. comm-div-info document . . . . . . . . . . . . . . . . . . . . 11 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 9.1. Communication Diversion Information Event Package 92 Registration . . . . . . . . . . . . . . . . . . . . . . . 12 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Introduction 101 3GPP is currently maintaining and specifying communication diversion 102 mechanisms which allow users to forward and/or redirect incoming 103 communications to other destinations. The intention of such 104 mechanisms is to provide users with sufficient flexibility to manage 105 their incoming communications in a better way. The most common 106 example is Communication Forward On Busy (CFB) where in users can 107 forward any incoming calls, whilst they are busy on some other call, 108 to their voice mail or a suitable alternative (e.g. some other user). 109 Similarly other variants of communication diversion are well defined 110 and used in practice such as Communication Forward on No Answer 111 (CFNA), Communication Forward Unconditional (CFU). Similarly 3GPP is 112 currently maintaining and specifying a mechanism for Users to 113 configure Communication Diversion Services ([1] and [2]) for their 114 incoming communications. The intention of such mechanisms is to 115 provide Users with sufficient flexibility to manage their incoming 116 communications in a better way. 118 However, with the increasing usage of Communication Diversion 119 services, users may have many different variants and configurations 120 active at the same time. For e.g. the user may have various CFU 121 services configured differently based on the time-of-the-day and the 122 Calling party's identity, or CFB based on the time-of-the-day. This 123 is possible by having various such configured diversions by 124 subscribing to different Communication Diversion (CDIV) services as 125 specified by 3GPP. Though, there has been quite active work in the 126 area of better customization and configuration of such Communication 127 Diversion mechanisms, not much attention has been paid to how the 128 Users can manage these services in an effective manner. With the 129 various advanced options and high flexibility provided, it is 130 possible that the User loses track of the various Communication 131 Diversion configurations or services they have registered for. 133 One of the basic ways, by which users can manage a CDIV service is to 134 be informed of which services they have registered for. For example, 135 [1] and [2] allow for such indications to be received by the user, at 136 the time of initiating an outgoing call. However, simply showing the 137 registered services is not sufficient, since each service may be 138 customized in numerous and different ways for different criteria. 139 For example various instantiations of CFB may be configured for 140 different times-of-the-day and different calling party identities. 141 Even if users are shown information about all the Communication 142 Diversion services and their variants that they are registered for, 143 they may not be able to make sense or verify that each of them is 144 correct as per their *expectation*. Such a mismatch in terms of 145 service behavior expectation and actual execution, may happen due to 146 incorrect configuration on behalf of the User, which cannot be easily 147 detected if there are various communication diversion services and 148 their different configurations for handling incoming communications. 150 A probable and suitable instance, when the User may easily judge 151 whether a communication diversion is correct, is when it actually 152 takes place. The User is already aware of the current conditions 153 (time-of-day, current presence and availability etc) and hence is in 154 a position to decide, whether the communication diversion which just 155 occurred, was indeed as per their expectation. For e.g. the User 156 wanted to diverted all incoming calls to voice-mail, between 3.00 157 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration 158 as 3.00 to 4.00 p.m. It would be very difficult for her to spot this 159 error while manually reviewing her complete set of communication 160 diversion services, with their various configurations. Instead, if 161 the User receives a real-time notification of any communication 162 diversion occurring after 4 p.m., she would be able to immediately 163 guess that something is 'wrong' or not as per her intention and take 164 corrective action. Such corrective action could be manual 165 verification of the specific rule which triggered the communication 166 diversion, wherein she will be able to spot the *mistake* more 167 easily. 169 Thus, for effective user management of multiple configurations of 170 various Communication Diversion services, a notification-based 171 mechanism may work well. Such a mechanism would involve notifying 172 users about diversions of their incoming communications, as and when 173 the communication diversion happens or with a slight delay (as per 174 user configuration). As such diversion-related information is 175 conveyed almost instantly or within a small time-frame, the Users can 176 verify whether the particular communication diversion is indeed 177 correct at that instant of time. 179 In this document, We define a SIP event package that allows a SIP 180 Event Publication Agent (EPA) to be notified about communication 181 diversions enacted on their behalf. This allows subscribers to 182 subscribe to this event package to gather this information. When 183 subscribing to the event package users can control how they want to 184 receive such notifications, the content and rate of such 185 notifications. It is believed that the SIP event package defined 186 here is not applicable to the general Internet: it has been designed 187 to serve the architecture of the CDIV service. The aim of this memo 188 is to follow the procedure indicated in RFC 3427 [3] and to register 189 a new event package with event name "comm-div-info" with IANA. 191 This document replaces the earlier document 192 draft-saklikar-communication-diversion-notification-00. 194 2. Terminology 196 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 197 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 198 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 199 indicate requirement levels for compliant implementations. 201 3. Applicability Statement 203 The event package defined in this document is intended for use with 204 network-based application servers that provide a CDIV service 206 4. Abbreviations and Definitions 208 4.1. Abbreviations 210 CDIV: Communication Diversion. 212 CDIVN: Communication Diversion Notification. 214 TISPAN: Telecommunications and Internet Converged Services and 215 Protocols for Advanced Networking. 217 4.2. Definitions 219 Diverting User - The user who has configured a Communication. 220 Diversion mechanism via subscription to a CDIV service. This user 221 is the original target of the incoming communication, before it is 222 diverted to another destination. When not qualified, the term 223 "user" should be referred to as the Diverting User. 225 Diverted-To Entity/User - This User (or entity) is the new target 226 of the incoming communication, post execution of any configured 227 Communication Diversion service. 229 Originating User - This refers to the originator of the incoming 230 communication, which was initially targeted towards the Diverting 231 User, but finally sent to the Diverted-To User. The Originating 232 User is also referred to as the Caller. 234 5. Requirements 236 A comprehensive description of all the requirements that affect the 237 CDIV service developed by TISPAN and 3GPP and can be found in the 238 3GPP web page at http://www.3gpp.org and http://www.etsi.org. 240 For the sake of simplicity, we briefly discuss here those 241 requirements that affect the solution described in this document. 242 These requirements can be summarized as follows: 244 o There must be a mechanism that allows user-controlled notification 245 of communication diversions to the diverting user, including the 246 option to control which notifications the user wants to receive 247 and to control the rate at which notifications are received. 249 o There must be a mechanism that enables filtering of notifications 250 of communication diversion. 252 o There must be a mechanism that enables triggering of notifications 253 of communication diversion. 255 o There must be a mechanism that enables selecting information to be 256 included in notifications of communication diversion. 258 These requirements lead to a solution whereby the user can indicate 259 to a network node his interest in receiving certain type of 260 notifications of communication diversion. Pushing these settings to 261 a network node allows the network node to conserve scarce resources 262 while still notifying the user of communication diversions enacting 263 on the user's behalf. 265 6. Package Definition 267 This section fills in the details needed for an event package as 268 defined in Section 4.4 of [5]. 270 6.1. Event Package Name 272 The SIP Events specification requires package definitions to specify 273 the name of their package or template-package. 275 The name of this package is "comm-div-info". As specfied in [5], 276 this value appears in the Event header present in SUBSCRIBE and 277 NOTIFY requests. 279 6.2. Event Package Parameters 281 The SIP Events specification [5] requires package and template- 282 package definitions to specify any package specific parameters of the 283 Event header that are used by it. 285 No package specific Event header parameters are defined for this 286 event package. 288 6.3. SUBSCRIBE bodies 290 The SIP Events specification requires package or template-package 291 definitions to define the usage, if any, of bodies in SUBSCRIBE 292 requests. 294 A SUBSCRIBE for Communication Diversion event MAY contain a body. 295 The purpose of the body depends on its type. Subscriptions to the 296 Comm-div-info event package typically include a body of MIME type 297 "application/comm-div-info+xml". 299 A body of the SUBSCRIBE request with content type set to MIME type 300 "application/comm-div-info+xml" contains information about filtering 301 communication diversions, trigger communication diversion 302 notifications and selecting information to be included in 303 communication diversions notifications. 305 6.4. Subscription Duration 307 The SIP Events specification requires package definitions to define a 308 default value for subscription durations, and to discuss reasonable 309 choices for durations when they are explicitly specified. 311 No expiration time for subscriptions withing this package is defined 312 in this document. The subscriber MAY specify an expiration value in 313 the expires header field. 315 6.5. Notify bodies 317 The SIP Events specification requires package definitions to define a 318 default value for subscription durations, and to discuss reasonable 319 choices for durations when they are explicitly specified. 321 The NOTIFY message contains bodies. This body is a format listed in 322 the Accept header field of the SUBSCRIBE request or a package 323 specific default format if the Accept header field was omitted from 324 the SUBSCRIBE request. 326 In this event package, the body of the notification contains comm- 327 div-info information when the diversion notifications occur. See 328 Section 7. 330 All subscribers and notifiers of the "comm-div-info" event package 331 MUST support the "application/comm-div-info+xml" data format 332 described in Section 7. The SUBSCRIBE request MAY contain an Accept 333 header field. If no such header field is present, it has a default 334 value of "application/comm-div-info+xml" (assuming Event header has a 335 value of "comm-div-info"). If the Accept header field is present, it 336 MUST contain the value "application/comm-div-info+xml". 338 6.6. Notifier Processing of SUBSCRIBE requests 340 The contents of a document containing comm-div-info information can 341 contain sensitive information that can reveal some privacy 342 information. Therefore, such comm-div-info documents MUST only be 343 sent to authorized subscribers. In order to determine if a 344 subscription originates in an authorized user, the user MUST be 345 authenticated as described in Section 6.6.1 and then the user MUST be 346 authorized to be a subscriber as described in Section 6.6.2. 348 6.6.1. Authentication 350 Notifiers MUST authenticate all subscription requests. This 351 authentication can be done using any of the mechanisms defined in [6] 352 and other authentication extensions. 354 6.6.2. Authorization 356 Once authenticated, the notifier makes an authorization decision. A 357 notifier MUST NOT accept a subscription unless authorization has been 358 provided by the user. The means by which authorization are provided 359 are outside the scope of this document. Authorization may have been 360 provided ahead of time through access lists, perhaps specified in a 361 web page. Authorization may have been provided by means of uploading 362 some kind of standardized access control list document 364 6.7. Notifier Generation of NOTIFY requests 366 The SIP Events specification details the formatting and structure of 367 NOTIFY messages. However, packages are mandated to provide detailed 368 information on when to send a NOTIFY, how to compute the state of the 369 resource, how to generate neutral or fake state information, and 370 whether state information is complete or partial. This section 371 describes those details for the "comm-div-info" event package. 373 A notifier MAY send a NOTIFY at any time. Typically, it will send 374 one when a communication diversion is enacted on behalf of the user. 375 The NOTIFY request MAY contain a body containing a comm-div-info 376 document. The times at which the NOTIFY is sent for a particular 377 subscriber, and the contents of the body within that notification, 378 are subject to any rules specified by the authorization policy that 379 governs the subscription and to preferences indicated at the time of 380 subscription. 382 In the case of a pending subscription, when final authorization is 383 determined, a NOTIFY can be sent. If the result of the authorization 384 was success and a communication diversion is enacted on behalf of the 385 subscriber, a NOTIFY SHOULD be sent and SHOULD contain a complete 386 comm-div-info document subject to any rules specified by the 387 authorization policy that governs the subscription and to preferences 388 indicated at the time of subscription. 390 The body of the NOTIFY MUST be sent using the type "application/ 391 comm-div-info+xml". 393 Notifiers will typically detect that a communication diversion was 394 enacted on behalf of the subscriber via a "History-Info" header field 395 value, per [2] or [1], sent from an application server hosting the 396 CDIV application. 398 6.8. Subscriber Processing of NOTIFY Requests 400 The SIP Events specification expects event packages to describe the 401 process followed by the subscriber upon receipt of a NOTIFY request. 402 In this specification, each NOTIFY request contains a comm-div-info 403 document 405 6.9. Handling of Forked Requests 407 The SIP Events specification requires each package to describe 408 handling of forked Requests. 410 This specification only allows a single dialog to be constructed as a 411 result of emitting an initial SUBSCRIBE request. This guarantees 412 that only a single notifier is generating notifications for a 413 particular subscription to a particular user. 415 6.10. Rate of Notifications 417 The SIP Events specification requires each package to specify maximum 418 rate at which notifications can be sent . 420 Comm-div-info notifiers SHOULD NOT generate notifications for a 421 single user at a rate of more than once every five seconds. 423 6.11. State Agents 425 The SIP Events specification requires each package to consider the 426 role of state agents in the package and, if they are used, to specify 427 how authentication and authorization are done 429 This specification does not require state agents to be located in the 430 network 432 6.12. Examples 434 An example of a comm-div-info document is provided in [2] and [1]. 435 An instance of a communication diversion notification subscription 436 document and an instance of a communication diversion notification 437 document can be found in subclause 4.10.1 of either [2] or [1]. 439 6.13. Use of URIs to Retrieve State 441 The SIP Events specification allows packages to use URIs to retrieve 442 large state documents. 444 Comm-div-info documents are fairly small. This event package does 445 not provide a mechanism to use URIs to retrieve large state 446 documents. 448 7. comm-div-info document 450 Comm-div-info is an XML document [7] that MUST be well-formed and 451 SHOULD be valid. Comm-div-info documents MUST be based on XML 1.0 452 and MUST be encoded using UTF-8 [8]. 454 Comm-div-info documents are identified with the MIME type 455 "application/comm-div-info+xml" and are instances of the XML schema 456 defined in subclause 4.10.2 of either [2] or [1]. 458 8. Security Considerations 460 Authentication and authorization of subscriptions have been discussed 461 in Section 6.6. Lack of authentication or authorization may provide 462 comm-div-info information to unauthorized parties and can reveal 463 sensitive information with regards to the user's call receiving 464 patterns. For example, who calls the user and at what time, etc. 466 Integrity protection and confidentiality of notifications are also 467 discussed in Section 6.7. If a notifier does not encrypt bodies of 468 NOTIFY requests, an eavesdropper could learn the status of a SIP user 469 agent and use it to create malicious sessions. If the notifier does 470 not integrity protect the bodies of NOTIFY requests, a man-in- the- 471 middle attacker or malicious SIP proxy could modify the contents of 472 the comm-div-info event package notification. Although this does not 473 cause harm, it can create annoyances. 475 9. IANA Considerations 477 This document registers the new SIP event package. 479 9.1. Communication Diversion Information Event Package Registration 481 This document registers an event package based on the registration 482 procedures defined in [3]. The following is the information required 483 for such a registration. 485 Package Name: comm-div-info 487 Package or Template-Package: This is a package 488 Published Document: RFC XXXX (Note to RFC Editor: 489 Please fill in XXXX with the RFC number of this specification). 490 Person to Contact : Jon Merdith (John.meredith@3gpp.org) 492 10. Acknowledgements 494 The authors would like to thank Samir Saklikar for editing the 495 initial version of the draft and Ban Al-Bakri, Roland Jesske and Jose 496 Miguel Torres for their valuable comments and suggestions. 498 11. References 500 11.1. Normative References 502 [1] 3GPP, "Communication Diversion (CDIV) using IP Multimedia 503 (IM)Core Network (CN) subsystem; Protocol specification", 3GPP 504 TS 24.604 8.2.0, December 2008. 506 [2] 3GPP, "TISPAN; PSTN/ISDN simulation services: Communication 507 Diversion (CDIV); Protocol specification", 3GPP TS 24.404 7.3.0, 508 December 2008. 510 [3] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 511 Rosen, "Change Process for the Session Initiation Protocol 512 (SIP)", BCP 67, RFC 3427, December 2002. 514 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 515 Levels", BCP 14, RFC 2119, March 1997. 517 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 518 Notification", RFC 3265, June 2002. 520 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 521 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 522 Session Initiation Protocol", RFC 3261, June 2002. 524 11.2. Informative References 526 [7] Paoli, J., Bray, T., Maler, E., and C. Sperberg-McQueen, 527 "Extensible Markup Language (XML) 1.0 (Second Edition)", World 528 Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, 529 . 531 [8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 532 J., and J. Rosenberg, "Common Policy: A Document Format for 533 Expressing Privacy Preferences", RFC 4745, February 2007. 535 Authors' Addresses 537 Ranjit Avasarala 538 Motorola India Pvt Ltd 539 Bagamane Tech Park, C V Raman Nagar 540 Bangalore 560093 541 India 543 Email: ranjit@motorola.com 545 Subir Saha 546 Motorola India Pvt Ltd 547 Bagamane Tech Park, C V Raman Nagar 548 Bangalore 560093 549 India 551 Email: subir.saha@motorola.com 553 John Luc Bakker 554 Research In Motion Corporation 555 5000 Riverside Drive, Building 6, Suite 100 556 Irving, Texas 75039 557 USA 559 Email: jbakker@rim.com