Subject: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt

From: John-Luc Bakker <[email-masked]>
Date: Sun, 24 Mar 2013 19:06:16 +0000

Hi all,

A new version of draft-avasarala-dispatch-comm-div-notification-11 was made available. Note that at least one more revision of this draft may be required. For example, the MIME type is now proposed to be "vnd.3gpp.comm-div-info+xml" and the registration template for it is to be provisionally included in 3GPP TS 24.604. This will then cause the references from this draft to 3GPP TSes to be updated.

As the editor I took the freedom to greatly reduce the size of the draft by referencing to 3GPP TS 24.604 more extensively. The SIP Events specification (RFC 3265) requires that:
- bodies to be used as part of the event package are specified; or 
- detailed specifications for the syntax and semantics of such a body are cited.  
By citing to TS 24.604 more frequently, I greatly reduced the size of this draft; the detailed specification is and has always been in 3GPP TS 24.604. 

[Q] Do you have concerns with the principle of referencing more extensively to 3GPP TS 24.604?

Additionally, the following comments were received from the list:
- Could all mentioning of CDIVN only working on IMS / TISPAN be removed from the draft? CDIVN could just defined as a general service. 
[response] CDIVN depends on IMS / TISPAN-based CDIV features that are defined in 3GPP TS 24.604 and 3GPP TS 24.229. Additionally, over the years no CDIVN work has started outside of the 3GPP application world. 

- The draft does not mention anything about PUBLISH.
[response] The use case for PUBLISH is updating CDIV rules in the network due to pushing a DND button. This draft does not have "updating of CDIV rules" within its scope. This draft concerns itself with the registering of an event package name and describes a filter that causes notifications to be sent when a filter is matched and when a CDIV is detected. I.e. the information in the event package informs the UA if a diversion has occurred, CDIVN does not cause diversions to occur as suggested by the PUBLISH use case. 

- Paul pointed out the MIME type was missing. 
[response] The proposed MIME type that covers the XML Schema found in TS 24.604 is "vnd.3gpp.comm-div-info+xml". Again, TS 24.604 needs some updating to be aligned with this version of draft-avasarala-dispatch-comm-div-notification. TS 24.604 currently references draft-avasarala-dispatch-comm-div-notification-07. The aligning of TS 24.604 with the evolved draft-avasarala-dispatch-comm-div-notification will be completed shortly and will result in a draft-avasarala-dispatch-comm-div-notification-12.

- Paul asked a FSM question: "Is it really the intent that the state machine is affected by the subscriber filter? That seems wrong. That means that a subscription refresh that changes the filter criteria could lose an event. Also, is the FSM associated with the subscriber, or with the subscription? (IOW, if the same subscriber has two concurrent subscriptions, does it have two FSMs or one?)"
[response] The intended use of the event package is to notify a subscriber when a diversion occurs that matches a set of filters provided when subscribing. The FSM is per subscriber's URI. So a subscriber with multiple URIs can have multiple FSMs. Whenever a different (or first) set of rules is received, the FSM (re)starts in IDLE. Each transition in the FSM is caused by the detection of a diversion for the URI. The rules that cause a diversion to happen are different from the rules that cause a notification to happen. No notifications are missed, as long as the notified diversion matches a filter.

Kind regards,

	JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, March 24, 2013 12:32 PM
To: John-Luc Bakker
Cc: [email-masked]
Subject: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt

A new version of I-D, draft-avasarala-dispatch-comm-div-notification-11.txt
has been successfully submitted by John Luc Bakker and posted to the IETF repository.

Filename:	 draft-avasarala-dispatch-comm-div-notification
Revision:	 11
Title:		 A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service
Creation date:	 2013-03-24
Group:		 Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-notification-11.txt
Status:          http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notification
Htmlized:        http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-11
Diff:            http://www.ietf.org/rfcdiff?url2=draft-avasarala-dispatch-comm-div-notification-11

Abstract:
   3GPP and TISPAN are defining the protocol specification for the
   Communication Diversion (CDIV) service using IP Multimedia (IM) Core
   Network (CN) subsystem (IMS) supplementary service.  As part of CDIV,
   a SIP based event package is used for notifying users about
   diversions (re-directions or forwarding) of requests for
   communication sessions targetting the user.  This document defines
   the SIP event package to support subscription and notification of
   diversions.  The proposed event package is applicable to the CDIV
   supplementary service in IMS and may not be applicable to the general
   internet.

The IETF Secretariat

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.