SIPPING S. Saklikar Internet-Draft S. Saha Intended status: Informational R. Avasarala Expires: March 15, 2009 Motorola September 11, 2008 A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information draft-saklikar-comm-diversion-notification-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 March 15, 2009. Abstract This draft defines a Session Initiation Protocol (SIP) Event Notification Framework-based mechanism 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. The applicability of this event package includes 3GPP IMS. Saklikar, et al. Expires March 15, 2009 [Page 1] Internet-Draft SIP Communication Diversion Notification September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Abbreviations and Definitions . . . . . . . . . . . . . . . . 6 3.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 4. Communication Diversion Notification framework . . . . . . . . 6 4.1. Communication Diversion Information . . . . . . . . . . . 8 4.2. Communication Diversion Selection Criteria . . . . . . . . 8 4.3. Communication Diversion Notification Trigger Criteria . . 9 5. Communication Diversion Information Event Package . . . . . . 9 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 9 5.2. Event Package Parameters . . . . . . . . . . . . . . . . . 9 5.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. Selection of Communication Diversions for notification . . . . . . . . . . . . . . . . . . . . . 10 5.3.2. Triggering notification of selected Communication Diversions . . . . . . . . . . . . . . . . . . . . . . 12 5.3.3. Selecting Communication Diversion Information to be notified . . . . . . . . . . . . . . . . . . . . . 12 5.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13 5.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 14 5.6.1. Verifying Subscribing UE's Authorization . . . . . . . 15 5.6.2. Verifying Diverting User Identity registration for Communication Diversion services . . . . . . . . . . . 16 5.6.3. Validation of parameters within the SUBSCRIBE message body . . . . . . . . . . . . . . . . . . . . . 16 5.7. Notifier generation of NOTIFY requests . . . . . . . . . . 16 5.8. Subscriber processing of NOTIFY requests . . . . . . . . . 17 5.9. Rate of notifications . . . . . . . . . . . . . . . . . . 17 6. Communication Diversion Information . . . . . . . . . . . . . 17 6.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Structure of Communication Diversion Information . . . . . 18 6.3. Communication Diversion Subscription Information . . . . . 18 6.3.1. Selecting Communication Diversions . . . . . . . . . . 19 6.3.2. Triggering Communication Diversions . . . . . . . . . 20 6.3.3. Selecting Communication Diversion Information . . . . 22 6.4. Communication Diversion Notification Information . . . . . 22 6.4.1. originating-user-info . . . . . . . . . . . . . . . . 23 6.4.2. diverting-user-info . . . . . . . . . . . . . . . . . 23 6.4.3. diverted-to-user-info . . . . . . . . . . . . . . . . 23 6.4.4. diversion-time-info . . . . . . . . . . . . . . . . . 23 6.4.5. diversion-reason-info . . . . . . . . . . . . . . . . 23 6.4.6. diversion-rule-info . . . . . . . . . . . . . . . . . 23 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Saklikar, et al. Expires March 15, 2009 [Page 2] Internet-Draft SIP Communication Diversion Notification September 2008 8.1. Time-based trigger for notification of all Information about selected Communication Diversions . . . . . . . . . 29 8.1.1. Use-case . . . . . . . . . . . . . . . . . . . . . . . 29 8.1.2. Configuring the Communication Diversion Service . . . 29 8.1.3. Subscribing to Communication Diversion Information Notification . . . . . . . . . . . . . . . . . . . . . 30 8.1.4. Call Flow . . . . . . . . . . . . . . . . . . . . . . 31 8.1.5. Notification of Communication Diversion Information . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10.1. Communication Diversion Information Event package registration . . . . . . . . . . . . . . . . . . . . . . . 34 10.2. application/comm-div-info+xml MIME Registration . . . . . 35 10.3. URN Sub-Namespace Registration for urn:3gpp:params:xml:ns:comm-div-info . . . . . . . . . . . 35 10.4. XML Schema Registration . . . . . . . . . . . . . . . . . 36 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12.1. Normative References . . . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 39 Saklikar, et al. Expires March 15, 2009 [Page 3] Internet-Draft SIP Communication Diversion Notification September 2008 1. Introduction Communication Diversion mechanisms allow Users to forward and/or redirect incoming communications to other destinations. The most common example is Communication Forward on Busy (CFB) wherein users can forward any incoming calls, whilst they are busy on some other call, to their voice mail or a suitable alternative (for 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) etc. Using Call Processing Language (CPL) [5], users can specify various time-based, language-based, caller's identity-based criteria for diverting their incoming as well as outgoing communications. Similarly, 3GPP is standardizing a mechanism for Users to configure Communication Diversion Services ([1]) for their incoming communications, as a part of it's work related to PSTN/ISDN Simulation Services. 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 within the User's CPL script or 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 users can manage a CDIV service, is to be informed of which services they have registered for. For e.g. [1] allows for such indications to be received by the user, 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 users 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 mis-match in terms of Saklikar, et al. Expires March 15, 2009 [Page 4] Internet-Draft SIP Communication Diversion Notification September 2008 service behaviour expectation and actual execution, may happen due to incorrect configuration on behalf of the User, which 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 User may easily judge whether a communication diversion is correct, is when it actually takes place. The User 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 User 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 in the CPL script 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 User 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* much easily. Thus, for effective user management of multiple configurations of various Communication Diversion services, a notification-based mechanism may work well. Such a mechanism would involve notifying users about diversions of their incoming communications, as and when the communication diversion happens or with a slight delay (as per User configuration). As such diversion-related information is conveyed almost instantly or within a small time-frame, the Users can verify whether the particular communication diversion is indeed correct at that instant of time. In this document, we describe a SIP Event Notification framework- based mechanism of notifying users about their communication diversions. We further describe, how users can control how they want to receive such notifications, the content and rate of such notifications. 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 [12] and indicate requirement levels for compliant implementations. Saklikar, et al. Expires March 15, 2009 [Page 5] Internet-Draft SIP Communication Diversion Notification September 2008 3. Abbreviations and Definitions 3.1. Abbreviations CDIV: Communication Diversion CDIVN: Communication Diversion Notification TISPAN: Telecommunications and Internet Converged Services and Protocols for Advanced Networking 3.2. Definitions Diverting User - The user who has configured a Communication Diversion mechanism, either via subscription to a CDIV service or configuration of a CPL script. This user is the original target of the incoming communication, before it is diverted to another destination. When not qualified, the term "user" should be referred to as the Diverting User. Diverted-To Entity/User - This User (or entity) is the new target of the incoming communication, post execution of any configured Communication Diversion service. Originating User - This refers to 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 as the Caller. 4. Communication Diversion Notification framework In this section, we describe the proposed mechanism for notification of Communication Diversion information. As described earlier, the intention is to enable Users to receive notification of information about diversions of their incoming communications. Such capability would enable the Users to take a judicious decision, with regards to whether such diversions are indeed correct as per expectations at that instance.The following call-flow describes a high-level usage of the Communication Diversion Notification mechanism. The Communication Diversion Application Server (CDIV-AS) may be viewed as a CPL processing engine or any of the 3GPP CDIV Services. In this document, a Communication Diversion Notification Server (CDIVN-S) role is proposed, which will handle processing User subscription to the Communication Diversion Notification feature as well as generating the relevant User notifications. It must be noted that the CDIVN-S role is logical and may be merged with the CDIV-AS. Saklikar, et al. Expires March 15, 2009 [Page 6] Internet-Draft SIP Communication Diversion Notification September 2008 However, if deployed differently, they would need an appropriate protocol for carrying the Communication Diversion information between them. Though potentially useful, this document does not attempt to cover this path of Communication Diversion information flow. As shown in the figure, User-1 has configured for Call Forwarding Unconditional (CFU) towards User-2, at the CDIV Application Server (AS). When the User-1 receives an incoming communication from a Calling Party, then it is re-directed towards User-2 by the CDIV-AS as per the CFU configured by the User. This communication diversion information is sent towards the CDIVN-S which then makes a decision to notify the information towards the User, based on User subscription options. User1 CDIV-AS CDIVN-S User2 Caller | | | | | |(1) Enable CFU to User2 | | |-------->| | | | |(2) Ok | | | | |<--------| | | | |(3) Subscribe to Communication Diversion Notification |------------------>| | | |(4) Success | | | |<------------------| | | | |(5) Session Invite to User1@example.com | |<----------------------------| | |(6) CDIV AS executes Diversion for User1 | |(7) Session Invite from Caller@example.com | |------------------>| | | | | |(8) Call Established | | | |.........| | |(9) Inform about Comm Diversion | |-------->| | | |(10) Notification of Communication Diversion Information |<------------------| | | |(11) Success | | | |------------------>| | | |(12) User can verify correctness of Communication Diversion | | | | | The intention of the Communication Diversion Notification framework is to provide sufficient information to the Users, so as to enable them to make a decision with regards to correctness of their communication diversions. Hence, the framework must support the ability to carry all the relevant information which can help Users in Saklikar, et al. Expires March 15, 2009 [Page 7] Internet-Draft SIP Communication Diversion Notification September 2008 making that decision. Also, the Users must be able to appropriately configure the Notification procedure. This section lists the various information types which must be supported in the Communication Diversion Notification framework. 4.1. Communication Diversion Information The User should have access to the following as part of the notified Communication Diversion Information. 1. Information about the Originating Party. 2. URI of the Diverting Party 3. URI of the Diverted-To Party 4. Time of the Communication Diversion. 5. Reason for the Communication Diversion. 6. Identity of the rule which triggered the Communication Diversion. 4.2. Communication Diversion Selection Criteria The User should also be able to set various criteria for selecting a particular subset of communication diversions for notification. The end result is better management for the User, as they can now focus on only those specific communication diversions which may be important in a given context. Selection of Communication Diversions for notification must be based on the following criteria 1. Identity of the Originating Caller of Communication 2. Identity of the Diverting User Identity, for whom the incoming communication was diverted 3. Identity of the Diverted-To User to whom the communication has been diverted. 4. Time-Range of the Communication Diversion. 5. Reason for the Communication Diversion. Saklikar, et al. Expires March 15, 2009 [Page 8] Internet-Draft SIP Communication Diversion Notification September 2008 4.3. Communication Diversion Notification Trigger Criteria It cannot be assumed that a User would be able to review any communication diversion notifications, as and when the corresponding communication diversion occurs. For e.g. the User could be busy at that time, which was the reason in the first place for configuring the Communication Diversion. Thus, the User should have the flexibility for setting an appropriate criteria for receiving the selected notifications. It is expected that the Communication Diversions (which would be selected based on the above 'Communication Diversion Selection Criteria') be notified when one or more of the following criteria are met. 1. User specified time interval. 2. Presence-status of the Diverting User. Further, if the Communication Diversion Information could not be notified to the User (for e.g. due to the User being logged out, or un-reachable), then there should be a mechanism to buffer the notifications for a time-period configured by the User. 5. Communication Diversion Information Event Package This section fills in the details needed to specify an event package as defined in Section 4.4 of [3]. 5.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". This package name is carried in the Event and Allow-Events header as defined in [3]. Example: Event:comm-div-info 5.2. Event Package Parameters The SIP Events specification requires package and template-package definitions to specify any package specific parameters of the Event header that are used by it. No package specific Event header parameters are defined for this event package. Saklikar, et al. Expires March 15, 2009 [Page 9] Internet-Draft SIP Communication Diversion Notification September 2008 5.3. SUBSCRIBE Bodies The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests. The user MAY include a message body within the SIP SUBSCRIBE to control the Communication Diversion Information subscription. However, the message body is NOT mandatory and may be absent. If the message body is completely absent, then it indicates that the User has selected all information about all communication diversions to be notified immediately, on execution of the Communication Diversion. However, it is also possible that only some elements of the proposed message body are used, in which case the default policies, as mentioned further, would be applicable for the missing elements. 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".If the header field is present, it MUST include "application/comm-div-info+xml". If the User has specified a message body, then it acts as a filter to control which communication diversions the User has selected for notification, when they should be notified and what information about them should be notified. More specifically, it serves to control the following aspects of Communication Diversion Information notification. 5.3.1. Selection of Communication Diversions for notification The user would be able to select a specific subset of the overall communication diversions for notification. This helps the user to focus only on those communication diversions which may be important (for e.g the User may be interested in only diversions of calls from her boss). The User is able to set the following criteria for selecting the communication diversions which have to be notified. 1. Identity of the Originating User (Caller) of Communication - The identity specified over here will be compared with the identity of the Originating Caller in the incoming communication. 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 parameter may contain regular expressions, to allow the User to specify a range of identities of the originating callers. This is an optional parameter. If absent, then all diversions for communications from any caller would be considered for notification, subject to other filter criteria. Saklikar, et al. Expires March 15, 2009 [Page 10] Internet-Draft SIP Communication Diversion Notification September 2008 2. Identity of the Diverting User - The identity specified over here will be compared with the Request-URI of the Diverting User, for which the incoming Communication has been diverted. Only if there is a match, then information about this specific Communication Diversion would be notified to the subscribing user. This is an optional parameter. If absent, then Communication Diversions towards the Identity of the subscribing user would be considered for notification, subject to other filter criteria. 3. Identity of the Diverted-To User - The identity specified over here will be compared with the Request-URI of the Diverted-to User. Only if there is a match, then information about this specific Communication Diversion would be notified to the Diverting User. This parameter may contain Regular expressions. This is an optional parameter. If absent, then Communication Diversions towards any diverted-to User would be considered for notification, subject to other filter criteria. 4. Time-Range of the Communication Diversion - This specifies a time-range, within which all Communication Diversions would be notified to the subscribing User. If present, then any communication diversion outside of this time- range would NOT be notified. This is an optional parameter. If absent, then Communication Diversions happening at any time would be considered for notification, subject to other filter criteria. A time zone should be indicated. If a time-zone is not indicated the SUBSCRIBE shall be rejected with a SIP 489. 5. Reason for the Communication Diversion.- This parameter specifies that only those Communication Diversions, which match the specified reason of diversion should be selected for notification. This parameter is same as the "cause-param" parameter which is added in the History Info header as per Section 4.5.2.6.2.2 of [1]. Informative details of cause- param are also defined in Annex C of [1]. This is an optional parameter. If absent, then all communication diversions resulting due to any cause would be considered for notification, subject to other filter criteria. Saklikar, et al. Expires March 15, 2009 [Page 11] Internet-Draft SIP Communication Diversion Notification September 2008 5.3.2. Triggering notification of selected Communication Diversions As a part of the SUBSCRIBE message body, the User may specify further criteria to trigger the notification of those communication diversions, which were selected by the above mentioned criteria. The User can trigger notification based on the following 1. Time-Range This specifies a time at which notifications of communication diversion are sent to the user. It may 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. If absent, it indicates that notifications are sent immediately when the communication diversion takes place. A time zone should be indicated. If a time zone is not indicated, the SUBSCRIBE shall be rejected with a SIP 489. 2. Presence-status - This specifies a presence state of the User, within which the User expects to receive notifications about communication diversions. If absent, it indicates that notifications are sent immediately irrespective of user's availability information 3. Notification Buffer Interval - This specifies an optional element (in seconds) to overwrite the CDIVN Buffer Timer for which the CDIVN AS should store the CDIV Notification, if it cannot be delivered to the user, as per the criteria configured above. For example this would be required for buffering the notifications, if the user is logged out and the diversion is triggered due to CFNL/CFNRc, resulting in CDIVN for that diversion. The user may set Notification Buffer Interval value in seconds to a maximum value of 1 day. Also, if not configured by the user, the default value of 1 day (as configured by the network provider) is applicable. 5.3.3. Selecting Communication Diversion Information to be notified As a part of the SUBSCRIBE message body, the User may specify further criteria to enable/disable which information about the communication diversion should be notified. By default, ALL information about a communication diversion (as described in Section 5.5 ) would be notified. However, the user may use the following elements for DISABLING a particular kind of information from being notified. 1. Information about the Originating Party. 2. URI of the Diverting party. Saklikar, et al. Expires March 15, 2009 [Page 12] Internet-Draft SIP Communication Diversion Notification September 2008 3. URI of the Diverted-To party. 4. Time of the Communication Diversion. 5. Reason for the Communication Diversion. 6. Identity of the rule which triggered the Communication Diversion. 5.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. The subscription duration for this package defaults to the duration of the User's subscription to the Communication Diversion Services (either by uploading a CPL or subscribing to a CDIV service as specified in [1]). If the User un-subscribes from the Communication Diversion Service, then the user is also necessarily un-subscribed from the Communication Diversion Information Event package described in this document. 5.5. NOTIFY bodies The SIP Events specification requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header in the SUBSCRIBE request. The body of a notification of communication diversion would contain information about the communication diversion, as selected by the various filter criteria configured by the User in the SUBSCRIBE message body. If the SUBSCRIBE did not contain a message body, then all possible information about the communication diversion is notified to the User. The notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request. The XML event package is sent as the body of the NOTIFY method, would contain the following information (subject to the filter criteria) selected by the User as explained in Section 5.3.3 1. Identity of the Originating User (Caller) of Communication - This helps the Subscribing User to know the Calling User of the communication which was diverted. Saklikar, et al. Expires March 15, 2009 [Page 13] Internet-Draft SIP Communication Diversion Notification September 2008 2. Identity of the Diverting User - The Request-URI of the INVITE before the Communication Diversion Service was executed for the Diverting User is informed to the subscribing UE. This is required when the Subscribing entity is different from the Diverting User Identity and/or has subscribed for multiple Diverting User Identities. Herein, the Subscribing UE would be interested to know for which specific Diverting User Identity was the Communication Diversion triggered. 3. Identity of the Diverted-To User - The Diverted-to User Identity, to whom the Communication is being diverted can be informed to the Diverting User. 4. Time of the Communication Diversion - The time of the Communication Diversion is informed to the Diverting User. This helps the Subscribing User to identify and verify if indeed the communication diversions were expected and hence "correct" at those times. A time zone shall be indicated. 5. Reason for the Communication Diversion - The Reason for this Communication Diversion is the same as the cause-param which is added in the History-Info header (at the highest History Index) field as defined in [6] and specified in section 4.5.2.6.2.2 of [1]. This parameter describes the Diversion Reason at this particular hop (in case there are multiple hops due to multiple Communication Diversions) and helps the Subscribing User to ascertain that indeed the Reason for Diversion is as per their expectations. 6. Communication Diversion Rule - This identifies the Communication Diversion Rule (as described in Sec 4.9.1.2 of [1]) which was executed to result in the communication diversion, which is being notified to the User. It contains the 'id' attribute of Communication Diversion Rule defined in [7]. 5.6. Notifier processing of SUBSCRIBE requests This section describes the processing to be performed by the notifier upon receipt of a SUBSCRIBE request. The Notifier processes the SUBSCRIBE request by performing the following tasks Saklikar, et al. Expires March 15, 2009 [Page 14] Internet-Draft SIP Communication Diversion Notification September 2008 5.6.1. Verifying Subscribing UE's Authorization The Notifier MUST verify that the Subscribing UE is authorised to subscribe for the requested Communication Diversion Notification. One check which the Notifier entity must perform is validating that the Subscribing UE can subscribe for the specified Diverting User's Communication Diversion notifications. There are two specific scenarios possible 5.6.1.1. Subscribing UE Identity is same as the Diverting User Identity. Herein, it is the Diverting User who is subscribing for notifications of diversions of communications which were originally targeted to itself. It is RECOMMENDED that the Diverting User be allowed to subscribe to their own Communication Diversion Information, without the need for any additional authorization. This helps the User in tracking, which are the communications which they have missed due to diversions and take possible action towards verifying and correcting the rules regarding these communications. Yet, allowing such subscription would be based on the appropriate policies configured at the Notifier. 5.6.1.2. Subscribing UE Identity is different from the Diverting User Identity. Herein, the Subscribing UE Identity is different from the Diverting User Identity. Hence, there needs to be appropriate authorization for the Subscribing UE to gain access to the Communication Diversion Information of the Diverting User. The Subscribing UE and the Diverting User Identity may belong to the same human User. This allows the scenario wherein the User is subscribing to their communication Diversion information but from another of their devices or different identities. This has the advantage that they can monitor the various communication Diversions information from a particular device/identity of their choice. However, it is up to the configuration of appropriate administrative policies at the Notifier for permitting such subscriptions. It is also possible, that the Subscribing UE and the Diverting User Identity do not belong to the same human User. For e.g. some application or automata can subscribe to the Communication Diversion Information package for a particular User. As covered by the earlier case, such application/automata may be running on any of the User's devices registered to the same or different identities of the User. As a special case, it is possible that the Application/automata is running on some server and monitoring the User's communication diversions on-behalf-of the user. Indeed, for these various scenarios to work, appropriate authorization policies must be pre- Saklikar, et al. Expires March 15, 2009 [Page 15] Internet-Draft SIP Communication Diversion Notification September 2008 loaded at the Notifier. 5.6.2. Verifying Diverting User Identity registration for Communication Diversion services The Notifier MUST verify that the Diverting User Identity, as encoded within the SUBSCRIBE message body is registered to at least one Communication Diversion services. 5.6.3. Validation of parameters within the SUBSCRIBE message body 5.6.3.1. Validation of Time Zone Information The Notifier MUST verify that any Time related parameters within the SUBSCRIBE message body are qualified with appropriate Time Zone parameter. If the Time Zone parameter is not indicated, then the SUBSCRIBE must be rejected with the SIP 489 error code. Examples of the Time-related parameters are the Time-Range for selection of Communication Diversion and Time-Range for trigger the notification of Communication Diversion. 5.6.3.2. Validation of time interval value for buffering Notifications The Notifier MUST validate that the time interval configured by the Subscribing UE for buffering Notifications is less than the default value of 1 day (in seconds). If the value is not configured by the User or configured for a value greater than 1 day, then the Notifier will set the value to 1 day (86400 seconds). 5.7. Notifier generation of NOTIFY requests This section of an event package describes the process by which the notifier generates and sends a NOTIFY request. The Notifier is a logical role played by the Communication Diversion service provider. However, it can also be played by an entity which has access to the communication diversions for the User. When a Notifier receives indications about a diversion of an incoming communication for the User, it refers to the appropriate filter criteria (Section 5.3) for selecting the Communication Diversions to be notified, as configured by the User at the time of subscription. From this selected set of Communication Diversions, the Notifier selects the information to be notified based on the filter criteria configured by the Subscribing UE for Communication Diversion Information selection. Finally, based on the Notification Trigger criteria, the selected information would be notified to the Subscribing UE, through the appropriate NOTIFY message body as defined in Section 5.5. Saklikar, et al. Expires March 15, 2009 [Page 16] Internet-Draft SIP Communication Diversion Notification September 2008 In case, there are no configured filter criteria, then the default action of notifying all Communication Diversion-related information about all communication diversions to the User immediately, is followed. 5.8. Subscriber processing of NOTIFY requests The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific way and in particular how it uses the NOTIFY requests. The Subscribing UE on receiving the NOTIFY request (with the communication diversion notification information) may trigger suitable application logic for validating that the information about Communication Diversions is indeed as per User expectation. For example, this information may be rendered to the User. In case, the information does not match User expectation, then the User may modify the communication diversion rules by using the procedures outlined in [2]. 5.9. Rate of notifications The SIP Events framework mandates that packages define a maximum rate of notifications for their package. This event package notifies about diversions of incoming communications for the User and hence it is expected that there will not be too many notifications. However, in case the User is under a Denial of Service attack, with continuous incoming communication requests for the user, the notification rate of communication diversions information MAY be high. For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the Notifier not generate notifications for a single subscriber at a rate faster than once every 5 seconds. 6. Communication Diversion Information Communication Diversion Information is an XML document [4] that MUST be well-formed and SHOULD be valid. It MUST be based on XML 1.0 and MUST be encoded using UTF-8. 6.1. Namespace This specification makes use of XML namespaces for identifying communication diversion notification information documents and document fragments.The namespace URI for elements defined by this Saklikar, et al. Expires March 15, 2009 [Page 17] Internet-Draft SIP Communication Diversion Notification September 2008 specification is a URN using the namespace identifier '3gpp' defined by [8]. This URN is: urn:3gpp:params:xml:ns:comm-div-info 6.2. Structure of Communication Diversion Information The Communication Diversion Information is described by a hierarchal XML structure with the root element tag "comm-div-info". The Communication Diversion Information serves two purposes viz. for setting the filter criteria for selecting communication diversions for notification at the time of subscription and the information which is notified to the Subscribing Entity when the communication diversion occurs. Thus, the structure of the Communication Diversion Information can be split into two top-level categories as shown in the following diagram. comm-div-info + +------- comm-div-subs-info | +------- comm-div-ntfy-info A Communication Diversion Information document begins with the root element tag "comm-div-info". 6.3. Communication Diversion Subscription Information As explained in Section 5.3, the message body within a SUBSCRIBE is used for setting various filter criteria with regards to the notification of communication diversion information. A Communication Diversion Subscription Information element begins with the tag "comm- div-subs-info" and includes the following three categories as follows. comm-div-subs-info + +------- comm-div-selection-criteria | +------- comm-div-ntfy-trigger-criteria | +------- comm-div-info-selection-criteria Saklikar, et al. Expires March 15, 2009 [Page 18] Internet-Draft SIP Communication Diversion Notification September 2008 6.3.1. Selecting Communication Diversions As explained in Section 5.3.1, the message body within a SUBSCRIBE can be used for selecting specific communication diversions, for notification to the User. It consists of the following sub-elements comm-div-selection-criteria + +------- originating-user-selection-criteria | +------- diverting-user-selection-criteria | +------- diverted-to-user-selection-criteria | +------- diversion-time-selection-criteria | +------- diversion-reason-selection-criteria 6.3.1.1. originating-user-selection-criteria This element contains a list of originating-user-info elements. If the incoming communication which was diverted was from an Originating User who is present in this list, then this communication diversion would be selected for notification. It has the following sub- elements List of user-info: Each element of this list is a user-info element, which is defined as follows. 6.3.1.1.1. user-info This is a generic element which contains information about a particular User. In this document, it is used for describing information about the Originating User (Caller) of the communication which was diverted. It has the following attributes user-name: Contains User Identity's display name. user-URI: Contains User Identity's SIP URI. 6.3.1.2. diverting-user-selection-criteria This element contains an address for the Diverting User. If the incoming communication which was diverted, was originally targeted towards this Diverting User, then this communication diversion would be selected for notification. Saklikar, et al. Expires March 15, 2009 [Page 19] Internet-Draft SIP Communication Diversion Notification September 2008 6.3.1.3. diverted-to-user-selection-criteria This element contains an address for the Diverted-to User. If the incoming communication was diverted towards this Diverted-to User, then this communication diversion would be selected for notification. 6.3.1.4. diversion-time-selection-criteria This element contains a list of time-ranges. If the incoming communication was diverted within one of the given time-ranges, then this communication diversion would be selected for notification. It has the following sub-elements List of time-ranges: Each element of this list is a time-range element, which is described in Section 6.3.2.1.1. 6.3.1.5. diversion-reason-selection-criteria This element contains a list of diversion-reason-info elements. If the incoming communication was diverted for a reason, which is present in this list, then this communication diversion would be selected for notification. It has the following sub-elements List of diversion-reason-info: Each element of this list is a diversion-reason-info element, which is described in Section 6.4.5. 6.3.2. Triggering Communication Diversions As explained in Section 5.3.2, the message body within a SUBSCRIBE can be used for selecting the trigger criteria for notifying the selected communication diversions to the Subscribing User. This allows the User to ensure that communication diversion notifications are not sent immediately, but when the user is in a suitable context (time-based or availability based). The following sub-elements are present for selecting the notification trigger criteria. The User also has an option to configure a buffer interval for which the notifications can be stored, if they are not deliverable to the User (for e.g. the User is Not logged in or is un-reachable). comm-div-ntfy-trigger-criteria + +------- time-range-selection-criteria | +------- presence-status-selection-criteria | +------- notification-buffer-interval Saklikar, et al. Expires March 15, 2009 [Page 20] Internet-Draft SIP Communication Diversion Notification September 2008 6.3.2.1. time-range-selection-criteria This element allows the specification of a list of time-ranges, when the User would like to be notified of communication diversion information. It has the following sub-elements time-range-selection-criteria + +------- time-range | + | +------- start-time | | | +------- end-time +------- time-range | +------- ... List of time-range: This contains a list of suitable time-ranges, when the User would like to be notified of the communication diversion information. Each element of this list is of the following type. 6.3.2.1.1. Time Range start-time: Contains a start time for the time-range. end-time: Contains the stop time for the time-range. 6.3.2.2. presence-status-selection-criteria This element allows the specification of a list of presence-status, when the User would like to be notified of communication diversion information. It has the following sub-elements presence-status-selection-criteria + +------- presence-status | +------- presence-status | +------- ... List of presence-status: This contains a list of presence-status: Indicates a presence-status for the User, when the User should be notified of communication diversion Saklikar, et al. Expires March 15, 2009 [Page 21] Internet-Draft SIP Communication Diversion Notification September 2008 information. 6.3.3. Selecting Communication Diversion Information As explained in Section 5.3.3, the message body within a SUBSCRIBE may be used for selecting the communication diversion information which has to be sent in the notification towards the User. This enables the User to select a specific sub-set of the overall diversion information. By default, ALL information would be provided to the User. However, the user may use any of the following sub- elements for DISABLING a particular kind of communication diversion information. comm-div-info-selection-criteria + +------- disable-originating-user-info | +------- disable-diverting-user-info | +------- disable-diverted-to-user-info | +------- disable-diversion-time-info | +------- disable-diversion-reason-info | +------- disable-diversion-rule-info The above elements do not have any further sub-elements. Their presence indicates that the User does NOT want that particular communication diversion information to be notified. 6.4. Communication Diversion Notification Information As part of the NOTIFY, the Notifier would generate a message body containing the communication diversion information, which the User had selected for notification as described above. This communication diversion information has the following sub-elements. A communication diversion information notification document begins with the element tag "comm-div-ntfy-info". Saklikar, et al. Expires March 15, 2009 [Page 22] Internet-Draft SIP Communication Diversion Notification September 2008 comm-div-ntfy-info + +------- originating-user-info | +------- diverting-user-info | +------- diverted-to-user-info | +------- diversion-time-info | +------- diversion-reason-info | +------- diversion-rule-info 6.4.1. originating-user-info This element contains the Identity of the Originating (Caller) of the communication which was diverted. It is of the type as described in Section 6.3.1.1.1 6.4.2. diverting-user-info This element contains the address of the Diverting User, whose incoming communication has been diverted. 6.4.3. diverted-to-user-info This element contains the address of the User to whom the incoming communication has been diverted to. 6.4.4. diversion-time-info This element contains the time at which the communication diversion took place. 6.4.5. diversion-reason-info This element contains the reason for the diversion. It can take on one of the following reason codes viz. "404", "486", "408", "302", "487", "480", "503". 6.4.6. diversion-rule-info This element contains the rule identifier that got executed as part of the communication diversion service. Saklikar, et al. Expires March 15, 2009 [Page 23] Internet-Draft SIP Communication Diversion Notification September 2008 7. XML Schema 8. Examples In this section, we describe various examples using the Communication Diversion Information document described earlier. 8.1. Time-based trigger for notification of all Information about selected Communication Diversions 8.1.1. Use-case The User is going to a meeting and hence would like all incoming communications to be diverted to his delegatee User-2 from 1 p.m. to 3 p.m. He would further like to be notified about all calls from this Boss, which were diverted when he gets out of the meeting. 8.1.2. Configuring the Communication Diversion Service The User subscribes to the Communication Diversion Service and configures a corresponding rule to divert all incoming calls from 1 p.m. to 3 p.m., towards User-2. The policy would look like the following Saklikar, et al. Expires March 15, 2009 [Page 29] Internet-Draft SIP Communication Diversion Notification September 2008 2006-05-06T013:00:00.000-05:00 2006-05-06T15:00:00.000-05:00 sip:User-2@example.com 8.1.3. Subscribing to Communication Diversion Information Notification The User subscribes to the Communication Diversion Information notification Service and configures that all diversions of communications from his Boss be notified to him at 3 p.m., when he returns from the meeting. The User would create and send the following message body in the SUBSCRIBE message whilst subscribing to the Communication Diversion Information event package. Saklikar, et al. Expires March 15, 2009 [Page 30] Internet-Draft SIP Communication Diversion Notification September 2008 Boss sip:boss@example.com 2006-05-06T013:00:00.000-05:00 2006-05-06T015:00:00.000-05:00 2006-05-06T015:00:00.000-05:00 2006-05-06T015:30:00.000-05:00 7200 8.1.4. Call Flow This section describes the call-flow for the given use-case. Saklikar, et al. Expires March 15, 2009 [Page 31] Internet-Draft SIP Communication Diversion Notification September 2008 User CDIV-AS CDIVN-S S-CSCF User-2 Boss Secretary |(1) Configure CFU to User-2 | | | | |-------->| | | | | | |(2) Ok | | | | | | |<--------| | | | | | |(3) SUBSCRIBE (comm-div-info) with Filter Criteria | |------------------>| | | | | |(4) 200 OK | | | | | |<------------------| | | | | | | | |(5) INVITE User@example.com | | | | |<------------------| | | |(6) INVITE User@example.com | | | | |<------------------| | | | | |(7) CDIV AS executes Diversion for User| | | |(8) INVITE User-2@example.com| | | | |------------------>| | | | | | | |(9) INVITE User-2@example.com| | | | |-------->| | | | | | | |(10) Call Setup | | | | | |.........| | | |(11) Inform about diversion of Boss's call | | |-------->| | | | | | | | |(12) INVITE User@example.com | | | | |<----------------------------| | | | | |(13) Same process as above | | | | |...................| | |(14) Inform about diversion of Secretary's call | | |-------->| | | | | | |(15) Verify User Subscription filter criteria | | |(16) It's 3 pm!! Trigger NOTIFY towards User | | | |(17) NOTIFY (comm-div-info) about Boss's Call | | |-------->| | | | |(18) NOTIFY (comm-div-info)about Boss' Call | | |<----------------------------| | | | |(19) 200 OK | | | | | |---------------------------->| | | | |(20) User can verify and take action | | | Steps 1 to 2: User registers and configures the CFU Communication Diversion service, with the Communication Diversion AS Steps 3 to 4: User subscribes to the Communication Diversion Information Event Package as described in this document. This subscription is sent to a Communication Diversion Information Notification service, with the appropriate SUBSCRIBE message body as described earlier. Steps 5 to 6: User receives an incoming INVITE from boss@example.com, Saklikar, et al. Expires March 15, 2009 [Page 32] Internet-Draft SIP Communication Diversion Notification September 2008 which is delivered to the CDIV AS to take any Communication Diversion related actions. Step 7: CDIV AS verifies that the User has registered for the CFU service, and executes it to forward/divert the incoming INVITE towards User-2@example.com. Steps 8 to 10: INVITE is forwarded towards User-2@example.com and call is setup with the Calling Party. The details of this Session setup are left out from this call-flow. Step 11: The CDIV AS sends information about the diversion to the CDIVN Service. This indication may not be required if the CDIVN-S is an additional role played by the CDIV AS. This document does not go into the details of defining this interface, if both the roles are deployed differently. Steps 12 to 13: Diverting User receives another INVITE from another user, which is similarly forwarded to User-2@example.com after execution of the CDIV CFU service. Step 14: Similar to Step 11, the CDIV AS sends information about the recent diversion to the CDIVN Service. Steps 15 to 16: CDIVN Service compares the received information with the Communiction Diversion Information selection and notification criteria as configured by the User in the SUBSCRIBE message. Based on the User configured trigger criteria, the CDIVN Service waits till any of the criteria are satisfied. In the given example, when the time is 3.00 pm, then the CDIVN Service creates and sends the NOTIFY with the Communiction Diversion Information message body. Steps 17 to 19: The NOTIFY along with the Communication Diversion Information message body is sent towards the User. Step 20: The information can be rendered to the User, who can then take corrective action in case the expected Communication Diversion rule execution is not as per expectation. 8.1.5. Notification of Communication Diversion Information The User is notified appropriately at the configured time-criteria of any Diversions for incoming communication from his Boss. The following exemplary message body is carried in the NOTIFY message. Saklikar, et al. Expires March 15, 2009 [Page 33] Internet-Draft SIP Communication Diversion Notification September 2008 Boss sip:boss@example.com sip:user@example.com sip:user-2@example.com 2006-05-06T014:00:00.000-05:00 404 rule66 9. Security Considerations Subscriptions to Communication Diversion Information can reveal sensitive information with regards to the User's Call receiving patterns. For e.g. who calls the User and at what time etc. For this reason, Section Section 5.6.1 provides guidelines on suitable authorization-related validations while accepting subscriptions for Communication Diversion Information event packaage. Since the data in notifications is sensitive as well, end-to-end SIP encryption mechanisms using S/MIME MAY be used to protect it. 10. IANA Considerations This document registers a new SIP event package, a new MIME type, application/comm-div-info+xml a new XML namespace, a new XML schema, and creates a sub-registry "URI purposes" under the existing registry: http://www.iana.org/assignments/sip-parameters 10.1. Communication Diversion Information Event package registration This specification 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 Saklikar, et al. Expires March 15, 2009 [Page 34] Internet-Draft SIP Communication Diversion Notification September 2008 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: Samir Saklikar (ssaklikar@gmail.com) 10.2. application/comm-div-info+xml MIME Registration MIME media type name: application MIME subtype name: comm-div-info+xml Mandatory parameters: (none) Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [4] Encoding considerations: Same as encoding considerations of application/xml as specified in [4] Security considerations: See Section 10 of [4] and Section 9 of this specification Interoperability considerations: This document provides a common format for exchange of Communication Diversion Information. Published specification: RFC XXXX (this document). Applications which use this media type: SIP Communication Diversion Information Notification applications Additional Information: This document intends to support the standardization requirements for the Communication Diversion Information Event Package as specified in [1] Personal and email address for further information: Samir Saklikar (ssaklikar@gmail.com) Intended usage: Limited Use, restricted to Communication Diversion Services and their Subscribing User clients. Author/Change controller: 3GPP 10.3. URN Sub-Namespace Registration for urn:3gpp:params:xml:ns:comm-div-info This section registers a new XML namespace, as per the guidelines in [9] URI: The URI for this namespace is urn:3gpp:params:xml:ns:comm-div-info Registrant Contact: IETF SIPPING Working Group (sipping@ietf.org) as designated by the IESG (iesg@ietf.org) XML: BEGIN: Saklikar, et al. Expires March 15, 2009 [Page 35] Internet-Draft SIP Communication Diversion Notification September 2008 Communication Diversion Information Namespace

Namespace for Communication diversion notification Information

urn:3gpp:params:xml:ns:comm-div-info

See RFCXXXX

END: 10.4. XML Schema Registration This specification registers a schema, as per the guidelines in [9] URI: please assign Registrant Contact: IETF SIPPING Working Group (sipping@ietf.org) as designated by the IESG (iesg@ietf.org) XML: The XML can be found as the sole content of Section 7 11. Acknowledgments Authors would like to thank Ban Al-Bakri, Roland Jesske and Jose Miguel Torres for their valuable comments and to John-Luc Bakker for specifically ensuring that this Internet draft is synchronized with the corresponding Communication Diversion Notification feature in 3GPP/TISPAN specifications. 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.0.0, June 2008. Saklikar, et al. Expires March 15, 2009 [Page 36] Internet-Draft SIP Communication Diversion Notification September 2008 [2] 3GPP, "PSTN/ISDN Simulation Services; Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating NGN PSTN/ISDN Simulation Services", 3GPP TS 24.423 8.1.0, June 2008. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [5] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004. [6] 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. [7] 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. [8] Monrad, A. and S. Loreto, "A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)", RFC 5279, July 2008. 12.2. Informative References [9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. Authors' Addresses Samir Saklikar Motorola Bagamane Tech Park, C.V.Raman Nagar Bangalore 560076 India Email: ssaklikar@gmail.com Saklikar, et al. Expires March 15, 2009 [Page 37] Internet-Draft SIP Communication Diversion Notification September 2008 Subir Saha Motorola Bagamane Tech Park, C.V.Raman Nagar Bangalore 560076 India Email: subir.saha@motorola.com Ranjit Avasarala Motorola Bagamane Tech Park, C.V. Raman Nagar Bangalore 560076 India Email: ranjit@motorola.com Saklikar, et al. Expires March 15, 2009 [Page 38] Internet-Draft SIP Communication Diversion Notification September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Saklikar, et al. Expires March 15, 2009 [Page 39]