idnits 2.17.1 draft-avasarala-dispatch-comm-div-notification-12.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (July 13, 2013) is 3933 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'IDLE' on line 431 == Unused Reference: '9' is defined on line 535, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4244 (ref. '8') (Obsoleted by RFC 7044) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH J. Bakker, Ed. 3 Internet-Draft BlackBerry Corporation 4 Intended status: Informational R. Avasarala 5 Expires: January 14, 2014 Polycom 6 July 13, 2013 8 A Session Initiation Protocol (SIP) Event Package for Communication 9 Diversion Information in support of the Communication Diversion (CDIV) 10 Notification (CDIVN) CDIV service 11 draft-avasarala-dispatch-comm-div-notification-12.txt 13 Abstract 15 3GPP and TISPAN are defining the protocol specification for the 16 Communication Diversion (CDIV) service using IP Multimedia (IM) Core 17 Network (CN) subsystem (IMS) supplementary service. As part of CDIV, 18 a SIP based event package is used for notifying users about 19 diversions (re-directions or forwarding) of requests for 20 communication sessions targetting the user. This document defines 21 the SIP event package to support subscription and notification of 22 diversions. The proposed event package is applicable to the CDIV 23 supplementary service in IMS and may not be applicable to the general 24 internet. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 14, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 63 4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 4 64 4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 65 4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 5 68 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 69 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6 70 6.3. SUBSCRIBE request bodies . . . . . . . . . . . . . . . . . 6 71 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6 72 6.5. NOTIFY request bodies . . . . . . . . . . . . . . . . . . 6 73 6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 7 74 6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7 75 6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 8 76 6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 8 77 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 78 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 8 79 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 80 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. Comm-div-info filter and notifier documents . . . . . . . . . 10 82 8. Structure of Comm-div-info filter and notifier formats . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. Communication Diversion Information Event Package 86 Registration . . . . . . . . . . . . . . . . . . . . . . . 11 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 3GPP is currently maintaining and specifying communication diversion 97 mechanisms which allow users to forward and/or redirect incoming 98 communications to other destinations. A common example is 99 Communication Forward On Busy (CFB) wherein users can instruct a 100 server in the network to redirect incoming requests, whilst they are 101 participating in a session. Similarly, other variants of 102 communication diversion are well defined and used in practice such as 103 Communication Forward on subscriber Not Reachable (CFNRc), 104 Communication Forward Unconditional (CFU), Communication Forwarding 105 No Reply (CFNR), Communication Deflection (CD), and Communication 106 Forwarding on Not Logged-in (CFNL). 3GPP is currently maintaining and 107 specifying a mechanism for users to configure Communication Diversion 108 Services (3GPP TS 24.504 [1] and its successor: 3GPP TS 24.604 [2]) 109 for their incoming communications. 111 The mechanism for users to configure Communication Diversion Services 112 (3GPP TS 24.504 [1]) may cause a variety of rules to be provisioned 113 in the network at the same time. For instance, a user may have, in 114 addition to other communication diversion rules, various CDIV 115 services configured, e.g. some rules based on the time-of-the-day and 116 some rules based on the calling party's identity. It is possible 117 that the user loses track of the various rules and undesirable 118 diversions may occur. If the user cann't notified of the diversions, 119 then it is hard for the user to determine that the combination of 120 rules have caused undesirable diversions. 122 CDIV Notification (CDIVN) is a CDIV service providing the user the 123 capability to receive notifications about all diverted communications 124 (CFU, CFB, CFNR, CD, CFNRc and CFNL). If CDIVN is configured, when a 125 communication is diverted on behalf of the subscriber, the Subcsriber 126 receives a notification. The subscriber is then in able to determine 127 whether the communication diversion which just occurred, was indeed 128 as per their expectation. For example, a subscriber intended to 129 divert all incoming calls to voice-mail, between 3.00 p.m. to 4.00 130 p.m. Yet, by mistake she configures the time-duration as 3.00 a.m. 131 to 4.00 p.m. It would be very difficult for her to spot this error 132 while manually reviewing her complete set of communication diversion 133 services, with their various configurations. Instead, if the 134 subscriber receives a real-time notification of any communication 135 diversion occurring after 4 p.m., she would be able to immediately 136 guess that something is 'wrong' or not as per her intention and take 137 corrective action. Such corrective action could be manual 138 verification of the specific rule which triggered the communication 139 diversion, wherein she will be able to spot the "mistake" more 140 easily. 142 Thus, for effective subscriber services management of multiple 143 configurations of various Communication Diversion services, a 144 notification-based mechanism may work well. Such a mechanism would 145 involve notifying subscribers about diversions of their incoming 146 communications, as and when the communication diversion happens or 147 with a slight delay (as per subscriber service configuration). As 148 such diversion-related information is conveyed almost instantly or 149 within a small time-frame, the subscribers can verify whether the 150 particular communication diversion is indeed correct at that instant 151 of time. 153 This document defines a SIP event package that allows a SIP User 154 Agents to subscribe to and be notified of communication diversions 155 enacted on their behalf using the CDIV service. The protocol 156 specification for the CDIV service (using IMS core networks) can be 157 found in 3GPP TS 24.504 [1]. 159 2. Terminology 161 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 162 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 163 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 164 indicate requirement levels for compliant implementations. 166 3. Applicability Statement 168 It is believed that the SIP event package defined here is not 169 applicable to the general Internet; it has been designed to serve the 170 architecture of the CDIV service (see 3GPP TS 24.504 [1]) in IMS core 171 networks 3GPP TS 24.229 (see [10]). The aim of this memo is to 172 follow the procedure indicated in RFC 5727 [4] and to register a new 173 event package with event name "comm-div-info" with IANA. 175 4. Abbreviations and Definitions 177 4.1. Abbreviations 179 CDIV: Communication Diversion. 181 CDIVN: Communication Diversion Notification. 183 TISPAN: Telecommunications and Internet Converged Services and 184 Protocols for Advanced Networking. 186 4.2. Definitions 188 Subscriber - The User Agent who has subscribed to the 189 Communication diversion notification service. 191 User - Another term for the subscriber. 193 Diverting User - The User Agent who has configured a Communication 194 Diversion. This could be the User Agent who has configured the 195 CDIV service rules in the network, in accordance with 3GPP TS 196 24.504 [1]. 198 Diverted-To Entity/User - The User Agent who is the new target of 199 the incoming communication, post execution of any configured CDIV 200 service rules. 202 Originating User - The User Agent who is the originator of the 203 incoming communication, which was initially targeted towards the 204 Diverting User, but finally sent to the Diverted-To User. The 205 Originating User is also referred to as the Caller. 207 IMS Core Network - This refers to the IMS based SIP based network 208 that conforms to the 3GPP TS 24.229 [10] and not the general SIP 209 network as defined in RFC 3261 [5]. 211 5. Requirements 213 The CDIVN service enables a user to receive notification about the 214 diversion of any of his/her incoming communications, which were 215 addressed to the user's address. A comprehensive description of all 216 the requirements that affect the CDIVN service developed by 3GPP and 217 TIPSAN is found in 3GPP TS 22.173 [6] and 3GPP TS 24.504 [1]. 219 6. Package Definition 221 This section fills in the details needed for an event package as 222 defined in RFC 6665 [7]. 224 6.1. Event Package Name 226 The SIP Events specification requires package definitions to specify 227 the name of their package or template-package. 229 The name of this package is "comm-div-info". As specified in RFC 230 6665 [7], this value appears in the Event header present in SUBSCRIBE 231 and NOTIFY requests. 233 6.2. Event Package Parameters 235 The SIP Events specification RFC 6665 [7] allows packages to define 236 additional parameters. This event package "comm-div-info" does not 237 define additional parameters. 239 6.3. SUBSCRIBE request bodies 241 The SIP Events specification requires package or template-package 242 definitions to define the usage, if any, of message bodies in 243 SUBSCRIBE requests. Furthermore, the SIP Events specification 244 requires that message bodies are specified or that detailed 245 specifications for the syntax and semantics of such a message body 246 are cited. 248 A SUBSCRIBE request for Communication Diversion event MAY contain a 249 message body. The purpose of the body depends on its type. 250 Subscriptions to the Comm-div-info event package SHALL only include a 251 message body of MIME type "application/vnd.3gpp.comm-div-info+xml". 252 The syntax and semantics of the message body can be found in 3GPP TS 253 24.504 [1]. 255 A body of the SUBSCRIBE request with content type set to MIME type 256 "application/comm-div-info-filter+xml" contains information about the 257 communication diversion notification information filter criteria and 258 notification trigger criteria. The subscriber SHALL also verify that 259 this information conforms to a valid XML document as defined in [11]. 260 The subscriber SHALL also verify that the information contained in 261 the XML document contains elements defined in 3GPP TS 24.504 [1]. 263 6.4. Subscription Duration 265 The default expiration time for subscriptions within this package is 266 3600 seconds. As per RFC 6665 [7], the subscriber MAY specify an 267 alternate expiration in the Expires header field. 269 6.5. NOTIFY request bodies 271 The SIP Events specification requires package definitions to define a 272 default value for subscription durations, and to discuss reasonable 273 choices for durations when they are explicitly specified. 275 The NOTIFY request message contains an event body. This event body 276 is in a format listed in the Accept header field of the SUBSCRIBE 277 request or a package specific default format if the Accept header 278 field was omitted from the SUBSCRIBE request. Furthermore, the SIP 279 Events specification requires that event bodies are specified or that 280 detailed specifications for the syntax and semantics of such a event 281 body are cited. 283 In this event package, the body of the notification contains the 284 communication diversion information pertaining to the diversion that 285 occurred in the network on behalf of the subscriber. The package 286 specific body has the MIME type "application/ 287 vnd.3gpp.comm-div-info+xml". The syntax and semantics of the event 288 body can be found in 3GPP TS 24.504 [1]. 290 A subscriber must always Accept receiving a NOTIFY request with 291 Content-Type "application/vnd.3gpp.comm-div-info+xml". The notifiers 292 MUST be capable of accepting the "application/ 293 vnd.3gpp.comm-div-info+xml" data format as described in 3GPP TS 294 24.504 [1]. If the notifier sends a NOTIFY, it MUST include contents 295 according to 3GPP TS 24.504 [1] and include the content-type header 296 field set to "application/vnd.3gpp.comm-div-info+xml". 298 The default Accept header field for SUBSCRIBE request is 299 "application/vnd.3gpp.comm-div-info+xml" (assuming Event header has a 300 value of "comm-div-info-ntfy"). 302 6.6. Notifier Processing of SUBSCRIBE requests 304 The contents of a "application/vnd.3gpp.comm-div-info+xml" XML 305 document in a NOTIFY request can contain sensitive information that 306 can reveal some privacy information. Therefore, such documents MUST 307 only be sent to authorized subscribers. In order to determine if a 308 subscription originates in an authorized user, the subscriber MUST be 309 authenticated as described in Section 6.6.1 and then the user MUST be 310 authorized to be a subscriber as described in Section 6.6.2. 312 The Notifier MUST check if the SUBSCRIBE request contains a body 313 part. If there is a body part, the Notifier MUST do the following. 315 Check if a SUBSCRIBE request body part conforms to "application/ 316 vnd.3gpp.comm-div-info+xml" XML Schema document in 3GPP TS 24.504 317 [1]. If it conforms then the Notifier processes the document and 318 generates notifications accordingly. 320 6.6.1. Authentication 322 Notifiers MUST authenticate all subscription requests. This 323 authentication can be done using any of the mechanisms defined in RFC 324 3261 [5] and other authentication extensions. 326 6.6.2. Authorization 328 Once authenticated, the notifier makes an authorization decision. A 329 notifier MUST NOT accept a subscription unless authorization has been 330 provided by the user. The means by which authorization are provided 331 are outside the scope of this document. 333 6.7. Notifier Generation of NOTIFY requests 335 The SIP Events specification details the formatting and structure of 336 NOTIFY request messages. However, packages are mandated to provide 337 detailed information on when to send a NOTIFY, how to compute the 338 state of the resource, how to generate neutral or fake state 339 information, and whether state information is complete or partial. 340 This section describes those details for the "comm-div-info" event 341 package. 343 A notifier sends a NOTIFY request when a communication diversion is 344 enacted on behalf of the user. If there is a stored filter criteria 345 for the user, then the notifier MUST look into the filter criteria. 346 If the filter criteria matches, then the notifier generates a NOTIFY 347 request and sends the NOTIFY request to the user. If the filter 348 criteria do not match, then the notifier does not generate a NOTIFY 349 request. A body part of the NOTIFY request has a content-type set to 350 "application/vnd.3gpp.comm-div-info+xml" and must contain the 351 elements defined in 3GPP TS 24.504 [1]. 353 Notifiers could detect that a communication diversion was enacted on 354 behalf of the subscriber via a "History-Info" header field RFC 4244 355 [8] value, per 3GPP TS 24.504 [1], sent from an application server 356 hosting the CDIV service. 358 6.8. Subscriber Processing of NOTIFY Requests 360 The SIP Events specification expects event packages to describe the 361 process followed by the subscriber upon receipt of a NOTIFY request. 362 In this specification, each NOTIFY request contains a XML document 363 for the content type "application/vnd.3gpp.comm-div-info+xml" (see 364 3GPP TS 24.504 [1]). 366 6.9. Handling of Forked Requests 368 The SIP Events specification requires each package to describe 369 handling of forked Requests. 371 This specification only allows a single dialog to be constructed as a 372 result of emitting an initial SUBSCRIBE request. This guarantees 373 that only a single notifier is generating notifications for a 374 particular subscription to a particular user. 376 But if forking is allowed, then the server that receives multiple 377 subscriptions should be able to generate a single dialog on behalf of 378 all the subscriptions that are received. Any subsequent 379 subscriptions should be mapped to the generated dialog. Similarly 380 when the server receives a single notification for the generated 381 dialog, it should be generate the corresponding number of 382 notifications towards the received notifications. 384 6.10. Rate of Notifications 386 The SIP Events specification requires each package to specify maximum 387 rate at which notifications can be sent . 389 Comm-div-info notifiers SHOULD NOT generate notifications for a 390 single subscription at a rate of more than once every five seconds. 392 6.11. State Agents 394 An FSM associated with the subscriber is created in the "IDLE" state, 395 e.g. upon receiving filter criteria. Whenever a communication 396 diversion is detected for a URI of the subscriber, a state transition 397 occurs. Depending on whether a filter is matched, a state is 398 entered. In the DIVERSION_NOTIFIED state, notification information 399 is sent to the subscriber. If notification information needs to be 400 sent, the Notifier generates the notification information and sends 401 the information to the subscriber. If a diversion is detected but no 402 filter is matched, a transition to DIVERSION_NOT_NOTIFIED occurs. 404 The FSM for CDIVN is shown in below Figure. 406 +-----------+ First diversion & Filter match 407 | +-------------------------------+ 408 | IDLE | | 409 | | | 410 +-----+-----+ | 411 First | | 412 diversion | | 413 & No | | 414 filter(s) | | 415 match V Next diversion & V 416 +-----------+ Filter match +-------+-------+ 417 | DIVERSION +---------------------->+ | 418 | NOT | | | DIVERSION | 419 | NOTIFIED +--+ +--+ NOTIFIED | 420 +-----+-----+ | +-------+-------+ 421 ^ | | 422 +--------+----------------------------+ 423 Next diversion & No filter(s) match 425 Figure 1: Diverted URI State Machine 427 The subscriber could receive, as part of the notification 428 information, the state the FSM was in prior to detecting the 429 diversion. 431 o [IDLE]: meaning that no diversions have occured since setting the 432 present "filter". 434 o [DIVERSION_NOTIFIED]: meaning that since receiving the last NOTIFY 435 request for this even package, no additional diversions have 436 occured. 438 o [DIVERSION_NOT_NOTIFIED]: meaning that one or more diversions have 439 occured since setting the present "filter" or since receiving the 440 last NOTIFY request for this even package. 442 7. Comm-div-info filter and notifier documents 444 Comm-div-info document is an XML document [11] that MUST be well- 445 formed and SHOULD be valid. Communication Diversion Information 446 documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 447 (see RFC 4745 [12]). 449 8. Structure of Comm-div-info filter and notifier formats 451 The 453 o structure of the filter and notifier format; 455 o examples of the use of subscribtion and notification bodies; and 457 o XML Schema of subscribtion and notification bodies, 459 have been described in 3GPP TS 24.504 [1]. 461 9. Security Considerations 463 Authentication and authorization of subscriptions have been discussed 464 in Section 6.6. Lack of authentication or authorization may provide 465 comm-div-info information to unauthorized parties and can reveal 466 sensitive information with regards to the user's call receiving 467 patterns. For example, who calls the user and at what time, etc. 469 Integrity protection and confidentiality of notifications are also 470 discussed in Section 6.7. If a notifier does not encrypt bodies of 471 NOTIFY requests, an eavesdropper could learn the status of a SIP user 472 agent and use it to create malicious sessions. If the notifier does 473 not integrity protect the bodies of NOTIFY requests, a man-in- the- 474 middle attacker or malicious SIP proxy could modify the contents of 475 the comm-div-info event package notification. Although this does not 476 cause harm, it can create annoyances. 478 10. IANA Considerations 480 This document registers the new SIP Event Package. 482 10.1. Communication Diversion Information Event Package Registration 484 Package Name: Comm-div-info 486 Type: Package 488 Contact: John Merdith, 490 Published Specification: RFC XXXX (Note to RFC Editor) 492 11. Acknowledgements 494 The authors would like to thank Mary Barnes, Samir Saklikar, Subir 495 Saha, Ban Al-Bakri, Roland Jesske, Jose Miguel Torres, Paul Kyzivat, 496 John Elwell , Keith Drage , Gonzalo Camarillo, Olle E. Johansson, 497 Atle Monrad and Dean Willis for their valuable comments and 498 suggestions. 500 12. References 502 12.1. Normative References 504 [1] 3GPP, "TISPAN; PSTN/ISDN simulation services: Communication 505 Diversion (CDIV); Protocol specification", 3GPP TS 24.504 506 8.17.0, June 2013. 508 [2] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM) 509 Core Network (CN) subsystem; Protocol specification", 3GPP 510 TS 24.604 10.6.0, June 2013. 512 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 513 Levels", BCP 14, RFC 2119, March 1997. 515 [4] Peterson, J., Jennings, C., and R. Sparks, "Change Process for 516 the Session Initiation Protocol (SIP) and the Real-time 517 Applications and Infrastructure Area", BCP 67, RFC 5727, 518 March 2010. 520 [5] 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 [6] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia 525 Telephony Service and supplementary services; Stage 1", 3GPP 526 TS 22.173 10.5.0, June 2012. 528 [7] Roach, A., "SIP-Specific Event Notification", RFC 6665, 529 July 2012. 531 [8] Barnes, M., "An Extension to the Session Initiation Protocol 532 (SIP) for Request History Information", RFC 4244, 533 November 2005. 535 [9] Jennings, C., Audet, F., and J. Elwell, "Session Initiation 536 Protocol (SIP) URIs for Applications such as Voicemail and 537 Interactive Voice Response (IVR)", RFC 4458, April 2006. 539 12.2. Informative References 541 [10] 3GPP, "IP multimedia call control protocol based on Session 542 Initiation Protocol (SIP) and Session Description Protocol 543 (SDP); Stage 3", 3GPP TS 24.229 10.12.0, June 2013. 545 [11] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray, 546 "Extensible Markup Language (XML) 1.0 (Second Edition)", World 547 Wide Web Consortium FirstEdition REC-xml-20001006, 548 October 2000, . 550 [12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 551 J., and J. Rosenberg, "Common Policy: A Document Format for 552 Expressing Privacy Preferences", RFC 4745, February 2007. 554 Appendix A. Change log 556 [RFC EDITOR NOTE: Please remove this section when publishing] 558 Changes from draft-avasarala-dispatch-comm-div-notification-11 560 o Updated affiliations 562 o Changed reference from RFC 3265 to RFC 6665 564 o Changed reference from 3GPP TS 24.604 to 3GPP TS 24.504 566 o Editorial clean up. 568 Changes from draft-avasarala-dispatch-comm-div-notification-10 570 o The SIP Events specification (RFC 3265) requires that bodies to be 571 used as part of the event package are specified or that detailed 572 specifications for the syntax and semantics of such a body are 573 cited. With that knowledge, the authors could greatly reduce the 574 size of this draft; the detailed specification is in 3GPP TS 575 24.504 and in 3GPP TS 24.604. 577 o Editorial clean up. 579 Changes from draft-avasarala-dispatch-comm-div-notification-09 581 o No changes of substance. An update addressing the comments on the 582 list and offline, will follow. 584 Changes from draft-avasarala-dispatch-comm-div-notification-08 586 o Corrected text to not preclude use of S/MIME or multipart. 588 o Updated Finite State Machine diagram. 590 o Updated the schema for CDIVN notification document to reflect FSM 591 updates. 593 Changes from draft-avasarala-dispatch-comm-div-notification-07 595 o Added MIME type for communication diversion filter criteria. 597 o Updated the State Agents section to add state diagram for CDIVN 598 Service. 600 o Updated the schema for CDIVN notification document. 602 o Updated the Acknowledgements section. 604 Changes from draft-avasarala-dispatch-comm-div-notification-06 606 o Changed the namespace for XML schema to "http://urn.etsi.org" 607 aligning with 3GPP TS 24.504 609 o Updated the XML schema and removed the word "optional" for 610 "diverting-user-info" 612 Changes from draft-avasarala-dispatch-comm-div-notification-05 614 o Updated Requirements section 616 o Incorporated expert review comments for state information, 617 notification content and subscribe bodies 619 o Modified the section on examples for subscription and notification 620 body 622 Changes from draft-avasarala-dispatch-comm-div-notification-04 624 o Incorporated review comments 626 o Added text for SUBSCRIBE request body and NOTIFY request body and 627 checking of filter criteria. 629 o Updated Communication Diversion Notification Information document 630 and XML schema to add Diversion and notification count information 631 as optional parameters. 633 Changes from draft-avasarala-dispatch-comm-div-notification-03 635 o Added State information to Notifiers. 637 o Modified diverting-URI definition and element in communication 638 diversion information selection criteria as optional parameter . 640 Changes from draft-avasarala-dispatch-comm-div-notification-02 642 o Modified the applicability statement to make it more IMS specific. 644 o Added a definition for IMS Core network. 646 o Updated authors list and Acknowledgement sections. 648 Changes from draft-avasarala-dispatch-comm-div-notification-01 650 o Incorporated review comments. 652 o Modified contact details for co author Subir Saha. 654 Changes from draft-avasarala-sipping-comm-div-notification-00 656 o Changed contact details of co author Subir Saha. 658 o Moved from SIPPING to DISPATCH WG. 660 Changes from draft-avasarala-dispatch-comm-div-notification-00 662 o Added comm-div-info document structure information and schema for 663 the event package. 665 o Added more elaborate description for various sections in comm-div- 666 info document 668 Authors' Addresses 670 John Luc Bakker (editor) 671 BlackBerry Corporation 672 5000 Riverside Drive, Building 6, Suite 100 673 Irving, Texas 75039 674 USA 676 Email: jbakker@blackberry.com 677 Ranjit Avasarala 678 Nokia Siemens Networks 679 Manyata Tech Park, Nagawara Outer Ring Road 680 Bangalore 560045 681 India 683 Email: ranjit.avasarala@nsn.com