DISPATCH R. Avasarala, Ed. Internet-Draft Motorola Inc Intended status: Informational J. Bakker Expires: January 28, 2010 Research In Motion Corporation S. Saha Mobivation July 27, 2009 A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service draft-avasarala-dispatch-comm-div-notification-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Avasarala, et al. Expires January 28, 2010 [Page 1] Internet-Draft SIP Communication Diversion Notification July 2009 Abstract 3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and in particular the Communication Diversion (CDIV) using IP Multimedia (IM) core Network (CN) subsystem supplementary service. As part of CDIV, a (SIP) Event Notification Framework-based mechanism is used for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. This SIP event package is applicable to the IMS and may not be applicable to the general Internet. Avasarala, et al. Expires January 28, 2010 [Page 2] Internet-Draft SIP Communication Diversion Notification July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 6 4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7 6.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 8 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 8 6.5. Notify bodies . . . . . . . . . . . . . . . . . . . . . . 8 6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 9 6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 9 6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 9 6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 9 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 10 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 10 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 10 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10 6.12. Use of URIs to Retrieve State . . . . . . . . . . . . . . 11 7. Comm-div-info Document . . . . . . . . . . . . . . . . . . . . 11 8. Structure of Comm-div-info Format . . . . . . . . . . . . . . 11 8.1. Comm-div-info Element . . . . . . . . . . . . . . . . . . 11 8.1.1. comm-div-subs-info Element . . . . . . . . . . . . . . 11 8.1.2. Comm-div-ntfy-info Element . . . . . . . . . . . . . . 14 8.1.3. Comm-div-info-selection-criteria . . . . . . . . . . . 14 8.2. Sample Notification body . . . . . . . . . . . . . . . . . 15 8.2.1. Instance of communication diversion subscription document . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.2. Instance of communication diversion notification document . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10.1. Communication Diversion Information Event Package Registration . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Avasarala, et al. Expires January 28, 2010 [Page 3] Internet-Draft SIP Communication Diversion Notification July 2009 1. Introduction 3GPP is currently maintaining and specifying communication diversion mechanisms which allow users to forward and/or redirect incoming communications to other destinations. The intention of such mechanisms is to provide users with sufficient flexibility to manage their incoming communications in a better way. The most common example is Communication Forward On Busy (CFB) where in users can forward any incoming calls, whilst they are busy on some other call, to their voice mail or a suitable alternative (e.g. some other user). Similarly other variants of communication diversion are well defined and used in practice such as Communication Forward on No Answer (CFNA), Communication Forward Unconditional (CFU). Similarly 3GPP is currently maintaining and specifying a mechanism for Users to configure Communication Diversion Services ([1] and [2]) for their incoming communications. The intention of such mechanisms is to provide Users with sufficient flexibility to manage their incoming communications in a better way. However, with the increasing usage of Communication Diversion services, users may have many different variants and configurations active at the same time. For e.g. the user may have various CFU services configured differently based on the time-of-the-day and the Calling party's identity, or CFB based on the time-of-the-day. This is possible by having various such configured diversions by subscribing to different Communication Diversion (CDIV) services as specified by 3GPP. Though, there has been quite active work in the area of better customization and configuration of such Communication Diversion mechanisms, not much attention has been paid to how the Users can manage these services in an effective manner. With the various advanced options and high flexibility provided, it is possible that the User loses track of the various Communication Diversion configurations or services they have registered for. One of the basic ways, by which subscribers can manage a CDIV service is to be informed of which services they have registered for. For example, [1] and [2] allow for such indications to be received by the subscriber, at the time of initiating an outgoing call. However, simply showing the registered services is not sufficient, since each service may be customized in numerous and different ways for different criteria. For example various instantiations of CFB may be configured for different times-of-the-day and different calling party identities. Even if subscribers are shown information about all the Communication Diversion services and their variants that they are registered for, they may not be able to make sense or verify that each of them is correct as per their *expectation*. Such a mismatch in terms of service behavior expectation and actual execution, may happen due to incorrect configuration on behalf of the User, which Avasarala, et al. Expires January 28, 2010 [Page 4] Internet-Draft SIP Communication Diversion Notification July 2009 cannot be easily detected if there are various communication diversion services and their different configurations for handling incoming communications. A probable and suitable instance, when the subscriber may easily judge whether a communication diversion is correct, is when it actually takes place. The subscriber is already aware of the current conditions (time-of-day, current presence and availability etc) and hence is in a position to decide, whether the communication diversion which just occurred, was indeed as per their expectation. For e.g. the subscriber wanted to diverted all incoming calls to voice-mail, between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration as 3.00 to 4.00 p.m. It would be very difficult for her to spot this error while manually reviewing her complete set of communication diversion services, with their various configurations. Instead, if the subscriber receives a real-time notification of any communication diversion occurring after 4 p.m., she would be able to immediately guess that something is 'wrong' or not as per her intention and take corrective action. Such corrective action could be manual verification of the specific rule which triggered the communication diversion, wherein she will be able to spot the *mistake* more easily. Thus, for effective subscriber services management of multiple configurations of various Communication Diversion services, a notification-based mechanism may work well. Such a mechanism would involve notifying subscribers about diversions of their incoming communications, as and when the communication diversion happens or with a slight delay (as per subscriber service configuration). As such diversion-related information is conveyed almost instantly or within a small time-frame, the subscribers can verify whether the particular communication diversion is indeed correct at that instant of time. This document defines a SIP event package that allows a SIP User Agents to subscribe to and be notified of communication diversions enacted on their behalf. This allows subscribers to subscribe to this event package to gather this information. When subscribing to the event package the subscribers can control how they want to receive such notifications, the content and rate of such notifications. It is believed that the SIP event package defined here is not applicable to the general Internet: it has been designed to serve the architecture of the CDIV service. The aim of this memo is to follow the procedure indicated in RFC 3427 [3] and to register a new event package with event name "comm-div-info" with IANA. Avasarala, et al. Expires January 28, 2010 [Page 5] Internet-Draft SIP Communication Diversion Notification July 2009 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations. 3. Applicability Statement The event package defined in this document is intended for use with network-based application servers that provide a CDIV service 4. Abbreviations and Definitions 4.1. Abbreviations CDIV: Communication Diversion. CDIVN: Communication Diversion Notification. TISPAN: Telecommunications and Internet Converged Services and Protocols for Advanced Networking. 4.2. Definitions Subscriber - The User Agent who has subscribed to the Communication diversion notification service. Diverting User - The User Agent who has configured a Communication Diversion. This could be the User Agent who has configured the Communication DIversion service rules in the network. Diverted-To Entity/User - The User Agent who is the new target of the incoming communication, post execution of any configured Communication Diversion service. Originating User - The User Agent who is the originator of the incoming communication, which was initially targeted towards the Diverting User, but finally sent to the Diverted-To User. The Originating User is also referred to as the Caller. 5. Requirements A comprehensive description of all the requirements that affect the CDIV service developed by TISPAN and 3GPP and can be found in the Avasarala, et al. Expires January 28, 2010 [Page 6] Internet-Draft SIP Communication Diversion Notification July 2009 3GPP web page at http://www.3gpp.org and http://www.etsi.org. For the sake of simplicity, we briefly discuss here those requirements that affect the solution described in this document. These requirements can be summarized as follows: o There must be a mechanism that allows subscriber-controlled notification of communication diversions to the diverting user, including the option to control which notifications the user wants to receive and to control the rate at which notifications are received. o There must be a mechanism that enables filtering of notifications of communication diversion. o There must be a mechanism that enables triggering of notifications of communication diversion. o There must be a mechanism that enables selecting information to be included in notifications of communication diversion. These requirements lead to a solution whereby the user can indicate to a network node his interest in receiving certain type of notifications of communication diversion. Pushing these settings to a network node allows the network node to conserve scarce resources while still notifying the user of communication diversions enacting on the user's behalf. 6. Package Definition This section fills in the details needed for an event package as defined in Section 4.4 of [5]. 6.1. Event Package Name The SIP Events specification requires package definitions to specify the name of their package or template-package. The name of this package is "comm-div-info". As specified in [5], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests. 6.2. Event Package Parameters The SIP Events specification [5] requires package and template- package definitions to specify any package specific parameters of the Avasarala, et al. Expires January 28, 2010 [Page 7] Internet-Draft SIP Communication Diversion Notification July 2009 Event header that are used by it. No package specific Event header parameters are defined for this event package. 6.3. SUBSCRIBE bodies The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests. A SUBSCRIBE for Communication Diversion event MAY contain a body. The purpose of the body depends on its type. Subscriptions to the Comm-div-info event package typically include a body of MIME type "application/comm-div-info+xml". A body of the SUBSCRIBE request with content type set to MIME type "application/comm-div-info+xml" contains information about filtering communication diversions, trigger communication diversion notifications and selecting information to be included in communication diversions notifications. 6.4. Subscription Duration The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified. No expiration time for subscriptions withing this package is defined in this document. The subscriber MAY specify an expiration value in the expires header field. 6.5. Notify bodies The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified. The NOTIFY message contains bodies. This body is a format listed in the Accept header field of the SUBSCRIBE request or a package specific default format if the Accept header field was omitted from the SUBSCRIBE request. In this event package, the body of the notification contains comm- div-info information when the diversion notifications occur. See Section 8. All subscribers and notifiers of the "comm-div-info" event package Avasarala, et al. Expires January 28, 2010 [Page 8] Internet-Draft SIP Communication Diversion Notification July 2009 MUST support the "application/comm-div-info+xml" data format described in Section 8. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/comm-div-info+xml" (assuming Event header has a value of "comm-div-info"). If the Accept header field is present, it MUST contain the value "application/comm-div-info+xml". 6.6. Notifier Processing of SUBSCRIBE requests The contents of a document containing comm-div-info information can contain sensitive information that can reveal some privacy information. Therefore, such comm-div-info documents MUST only be sent to authorized subscribers. In order to determine if a subscription originates in an authorized user, the subscriber MUST be authenticated as described in Section 6.6.1 and then the user MUST be authorized to be a subscriber as described in Section 6.6.2. 6.6.1. Authentication Notifiers MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in [6] and other authentication extensions. 6.6.2. Authorization Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading some kind of standardized access control list document 6.7. Notifier Generation of NOTIFY requests The SIP Events specification details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the "comm-div-info" event package. A notifier MAY send a NOTIFY at any time. Typically, it will send one when a communication diversion is enacted on behalf of the user. The NOTIFY request MAY contain a body containing a comm-div-info document. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that Avasarala, et al. Expires January 28, 2010 [Page 9] Internet-Draft SIP Communication Diversion Notification July 2009 governs the subscription and to preferences indicated at the time of subscription. The body of the NOTIFY MUST be sent using the type "application/ comm-div-info+xml". Notifiers could detect that a communication diversion was enacted on behalf of the subscriber via a "History-Info" header field value, per [2] or [1], sent from an application server hosting the CDIV application. 6.8. Subscriber Processing of NOTIFY Requests The SIP Events specification expects event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request. In this specification, each NOTIFY request contains a comm-div-info document 6.9. Handling of Forked Requests The SIP Events specification requires each package to describe handling of forked Requests. This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single notifier is generating notifications for a particular subscription to a particular user. 6.10. Rate of Notifications The SIP Events specification requires each package to specify maximum rate at which notifications can be sent . Comm-div-info notifiers SHOULD NOT generate notifications for a single subscription at a rate of more than once every five seconds. 6.11. State Agents The SIP Events specification requires each package to consider the role of state agents in the package and, if they are used, to specify how authentication and authorization are done This specification does not require state agents to be located in the network Avasarala, et al. Expires January 28, 2010 [Page 10] Internet-Draft SIP Communication Diversion Notification July 2009 6.12. Use of URIs to Retrieve State The SIP Events specification allows packages to use URIs to retrieve large state documents. Comm-div-info documents are fairly small. This event package does not provide a mechanism to use URIs to retrieve large state documents. 7. Comm-div-info Document Comm-div-info document is an XML document [11] that MUST be well- formed and SHOULD be valid. Communication Diversion Information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [12]. 8. Structure of Comm-div-info Format A Communications Diversion Information document starts with a "comm- div-info" element. The comm-div-info element has a series of elements describing the particular communication diversion or the filter criteria for receiving the communication diversion information. 8.1. Comm-div-info Element The comm-div-info element gives information about the specific communication diversion or it could give information about a particular selection criteria for the user receiving the communication diversion information. 8.1.1. comm-div-subs-info Element The comm-div-subs-info element is used by the subscribing user to specify the communication diversion information selection criteria and the communication diversion notification trigger criteria. It contains the following elements: 8.1.1.1. comm-div-selection-criteria This element contains information about communication diversion information selection criteria. It contains following sub-elements for specifying the selection criteria. Avasarala, et al. Expires January 28, 2010 [Page 11] Internet-Draft SIP Communication Diversion Notification July 2009 8.1.1.1.1. originating-user-selection-criteria This element specifies the originating user information for the communication i.e the caller. This is specified in the form of "user-name" and "user-uri". E.g sip:Alice@domain.com. The Username as well as User-URI specified will be compared with the originating user information of the current user and if there is a match, then information about the diversion of this specific communication would be selected for notification to the Diverting user. It consists of the following sub-elements. 8.1.1.1.1.1. user-info This element gives user details like username and URI. This element has further sub-elements for describing username and user URI 8.1.1.1.1.1.1. User-name This element gives Username. E.g "Alice". 8.1.1.1.1.1.2. User-URI This element gives User URI. E.g "sip:Alice@domain.com". It takes the form of any URI scheme like sip. sips, tel or any other URI scheme 8.1.1.1.2. diversion-time-selection-criteria This element specifies the time range for receiving notifications. It contains following additional elements . 8.1.1.1.2.1. time-range This element specifies the time range at which notifications for communication diversions can be sent to the subscriber. This could be specified in the form of a time-interval to enable periodic triggering of notifications of communication diversions which took place in that time-interval. 8.1.1.1.2.1.1. start-time This element is specifies the start time for receiving notifications. Its value is expressed in YYYY:MM:DDTHH:MM:SS:Z format. 8.1.1.1.2.1.2. end-time This element specifies the end time for receiving notifications. Its value is expressed in YYYY:MM:DDTHH:MM:SS:Z format. Avasarala, et al. Expires January 28, 2010 [Page 12] Internet-Draft SIP Communication Diversion Notification July 2009 8.1.1.1.3. diverting-user-selection-criteria This element gives details of diverting user. The URI specified over here will be compared with the Request URI of the diverting user for whom a communication has been diverted. Only if there is a match, then information about the diversion of this specific communication would be selected for notification to the Diverting user. This is an optional parameter. This element consists of sub-elements defined for "user-info" element Section 8.1.1.1.1.1.1. 8.1.1.1.4. diverted-to-user-selection-criteria This element gives details of the final target of the communication i.e the divered-to user. The URI specified in the Request URI of the new request is compared with the specified diverted-to URI. Only if there is a match, then information about the diversion of this specific communication would be selected for notification to the Diverting user. This element consists of sub-elements defined for "user-info" element Section 8.1.1.1.1.1.1. 8.1.1.1.5. diversion-reason-selection-criteria This element contains the reason for communication diversion. It contains following sub-element: 8.1.1.1.5.1. diversion-reason-info This element gives the actual reason for the communication diversion. 8.1.1.2. comm-div-ntfy-trigger-criteria 8.1.1.2.1. notification-time-selection-criteria This element informs the server about the time at which the notification should be triggered. 8.1.1.2.2. presence-status-selection-criteria This element gives the presence status of the subscriber, based on which the decision can be made, whether the subscriber wishes to receive notification information or not. 8.1.1.2.2.1. presence-selection-info This element specifies the presence status of the subscriber within which the subscriber expects to receive notifications about communication diversions. Avasarala, et al. Expires January 28, 2010 [Page 13] Internet-Draft SIP Communication Diversion Notification July 2009 8.1.1.2.3. notification-buffer-interval 8.1.2. Comm-div-ntfy-info Element This element gives the notification information. This element has following sub-elements: 8.1.2.1. originating-user-info Refer to Section 8.1.1.1.1 for details of this element. 8.1.2.2. diverting-user-info This element gives details of the diverting user. 8.1.2.3. diverted-to-user-info This element gives details of the final target of the communication i.e the divered-to user. This element consists of sub-elements defined for "user-info" element. 8.1.2.4. diversion-time-info This element gives the time of communication diversion. Its value is expressed in YYYY:MM:DDTHH:MM:SS format. 8.1.2.5. diversion-reason-info This element gives the actual reason for the communication diversion. 8.1.3. Comm-div-info-selection-criteria This element gives the subscriber various to select communication diversion information. This element has following sub-elements. 8.1.3.1. disable-originating-user-info This element gives the subscriber option of adding originating user information to the notification information. 8.1.3.2. disable-diverting-user-info This element gives the subscriber option of adding diverting-user information to the notification information. Avasarala, et al. Expires January 28, 2010 [Page 14] Internet-Draft SIP Communication Diversion Notification July 2009 8.1.3.3. disable-diverted-to-user-info This element gives the subscriber option of adding diverting-to-user information to the notification information. 8.1.3.4. disable-diversion-time-info This element gives the subscriber option of adding diversion-time information to the notification information. 8.1.3.5. disable-diversion-reason This element gives the subscriber option of adding diversion-time information to the notification information. 8.1.3.6. disable-diversion-rule This element gives the subscriber option of adding diversion-rule information to the notification information. 8.2. Sample Notification body Avasarala, et al. Expires January 28, 2010 [Page 15] Internet-Draft SIP Communication Diversion Notification July 2009 8.2.1. Instance of communication diversion subscription document Boss sip:boss@office.com 1999-05-31T13:20:00-05:00 2006-05-06T13:20:00-05:00 404 302 1999-05-31T13:20:00-05:00 2006-05-06T13:20:00-05:00 Avasarala, et al. Expires January 28, 2010 [Page 16] Internet-Draft SIP Communication Diversion Notification July 2009 8.2.2. Instance of communication diversion notification document Boss sip:boss@office.com sip:alice@office.com sip:bob@office.com 1999-06-01T13:20:00-05:00 404 8.3. Schema Avasarala, et al. Expires January 28, 2010 [Page 17] Internet-Draft SIP Communication Diversion Notification July 2009 Avasarala, et al. Expires January 28, 2010 [Page 19] Internet-Draft SIP Communication Diversion Notification July 2009 Avasarala, et al. Expires January 28, 2010 [Page 20] Internet-Draft SIP Communication Diversion Notification July 2009 9. Security Considerations Authentication and authorization of subscriptions have been discussed in Section 6.6. Lack of authentication or authorization may provide comm-div-info information to unauthorized parties and can reveal sensitive information with regards to the user's call receiving patterns. For example, who calls the user and at what time, etc. Integrity protection and confidentiality of notifications are also Avasarala, et al. Expires January 28, 2010 [Page 22] Internet-Draft SIP Communication Diversion Notification July 2009 discussed in Section 6.7. If a notifier does not encrypt bodies of NOTIFY requests, an eavesdropper could learn the status of a SIP user agent and use it to create malicious sessions. If the notifier does not integrity protect the bodies of NOTIFY requests, a man-in- the- middle attacker or malicious SIP proxy could modify the contents of the comm-div-info event package notification. Although this does not cause harm, it can create annoyances. 10. IANA Considerations This document registers the new SIP event package. 10.1. Communication Diversion Information Event Package Registration This document registers an event package based on the registration procedures defined in [3]. The following is the information required for such a registration. Package Name: Comm-div-info Package or Template-Package: This is a package Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification). Person to Contact : Jon Merdith (John.meredith@3gpp.org) 11. Acknowledgements The authors would like to thank Samir Saklikar for editing the initial version of the draft and Ban Al-Bakri, Roland Jesske, Jose Miguel Torres and Paul Kyzivat for their valuable comments and suggestions. 12. References 12.1. Normative References [1] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM)Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.604 8.4.0, June 2009. [2] 3GPP, "TISPAN; PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification", 3GPP TS 24.404 7.5.0, June 2009. Avasarala, et al. Expires January 28, 2010 [Page 23] Internet-Draft SIP Communication Diversion Notification July 2009 [3] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [7] Moats, R., "URN Syntax", RFC 2141, May 1997. [8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [10] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006. 12.2. Informative References [11] Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, . [12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. Appendix A. Change log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-avasarala-sipping-comm-div-notification-00 o Changed contact details of co author Subir Saha. Avasarala, et al. Expires January 28, 2010 [Page 24] Internet-Draft SIP Communication Diversion Notification July 2009 o Moved from SIPPING to DISPATCH WG. Changes from draft-avasarala-dispatch-comm-div-notification-00 o Added comm-div-info document structure information and schema for the event package. o Added more elaborate description for various sections in comm-div- info document Authors' Addresses Ranjit Avasarala (editor) Motorola India Pvt Ltd Bagamane Tech Park, C V Raman Nagar Bangalore 560093 India Email: ranjit@motorola.com John Luc Bakker Research In Motion Corporation 5000 Riverside Drive, Building 6, Suite 100 Irving, Texas 75039 USA Email: jbakker@rim.com Subir Saha CEO Mobivation B-602, Salarpuria Silverwood, C V Raman Nagar Bangalore 560093 India Email: drsubirsaha@yahoo.com Avasarala, et al. Expires January 28, 2010 [Page 25]