Subject: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09

From: John-Luc Bakker <[email-masked]>
Date: Wed, 9 May 2012 13:38:50 +0000

Hi,

I like to announce the availability of the draft below. 
Comments received during previous reviews have been addressed.

Kind regards,

	John-Luc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2012 2:55 PM
To: John-Luc Bakker
Cc: [email-masked]
Subject: New Version Notification for draft-avasarala-dispatch-comm-div-notification-09.txt

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

Filename:	 draft-avasarala-dispatch-comm-div-notification
Revision:	 09
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:	 2012-03-27
WG ID:		 Individual Submission
Number of pages: 29

Abstract:
   3GPP and TISPAN are defining the protocol specification for the
   Communication Diversion (CDIV) service using IP Multimedia (IM) Core
   Network (CN) subsystem supplementary service.  As part of CDIV, a SIP
   based Event package framework is used for notifying users about
   diversions (re-directions or forwarding) of their incoming
   communication sessions.  This document proposes a new SIP event
   package for allowing users to subscribe to and receive such
   notifications.  Users can further define filters to control the rate
   and content of such notifications.  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.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 May 2012 16:18:04 +0200

> Comments received during previous reviews have been addressed.

While reading this for the first time I find it strange that this is only aimed at the 3GPP application world.

I see many cases where I have network-controlled call forwarding and want all phones registred to my
AOR to get information that the AOR is forwarded.

Ideally I would like the SIP phone manufacturers to have their phones subscribe to this package.

Now if I press a DND button on my phone - will i PUBLISH an XML document to update my status in the server and enable a service? The draft does not mention anything about PUBLISH.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2012 10:58:26 -0400

I have reviewed many versions of this draft.
I'd appreciate it if somebody with a fresh set of eyes would give this a 
careful review.

	Thanks,
	Paul

On 5/9/12 9:38 AM, John-Luc Bakker wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2012 11:44:26 -0400

Comments on -09:

Section 6.6 now mentions (at my request) "body part" rather than "body". 
But its not just any body part - this should say the check is for a body 
part with the appropriate content-type. Perhaps:

    The Notifier MUST check if the SUBSCRIBE request contains a body
    part having content-type "application/comm-div-info-filter+xml".
    If so the Notifier processes the filter criteria and generates
    notifications accordingly.

Section 6.11:

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?)

Maybe this works as you intend, but I bring it up in case it doesn't.

(Also note that the first line of figure 1 is indented incorrectly.)

Section 10:

I just realized you have no MIME registrations for the mime types you 
use: "application/comm-div-info-ntfy+xml" and 
"application/comm-div-info-filter+xml". You really need that.

And that would need to specify the association between the mime type and 
the xml scheme element contained in the mime type. That presents a 
little complexity because, based on the examples you have, one top level 
xml element for both mime types. I guess you can do that if you explain 
it well enough, though IMO it would make more sense to dispense with 
<comm-div-info>, and use <comm-div-subs-info> as the top level element 
of "application/comm-div-info-filter+xml", and <comm-div-ntfy-info> as 
the top level element of "application/comm-div-info-ntfy+xml"

I think this document also requires a review by a MIME expert before it 
can be approved.

	Thanks,
	Paul

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Wed, 16 May 2012 17:24:02 +0800

Hi Oile

Though the abstract of the draft mentions 3GPP and IMS, the CDIVN service and the proposed event package holds good for any SIP based VoIP networks. So you could look at it as a generic SIP based event notification and event package conforming to RFC 3265. 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: Wednesday, May 09, 2012 7:48 PM
To: John-Luc Bakker
Cc: [email-masked]
Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09

I see many cases where I have network-controlled call forwarding and want all phones registred to my AOR to get information that the AOR is forwarded.

/O

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Wed, 16 May 2012 17:32:24 +0800

Hi Paul

Yes I agree with you that we need to register the 2 XML body types - application/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml as MIME type registrations.  Sorry we missed that. 

Section 6.11:

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?)

<Ranjit> FSM is actually associated with the call diversion service and not with the subscriber / subscription.  The state changes and notifications being sent or not depend on subscription. For e.g. if the subscriber has set a filter not to send notifications for diversions that occur between 9 PM and 6 AM, then the state would not transition to "Diversion Notified" for that particular diversion. Rather it would transition to "Diversion Not Notified". 

Let us know if there are any other comments before we can update the doc

Thanks

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, May 09, 2012 9:14 PM
To: [email-masked]
Subject: Re: [dispatch] comments requested for draft-avasarala-dispatch-comm-div-notification-09

Comments on -09:

Section 6.6 now mentions (at my request) "body part" rather than "body". 
But its not just any body part - this should say the check is for a body part with the appropriate content-type. Perhaps:

Section 6.11:

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?)

Section 10:

I just realized you have no MIME registrations for the mime types you
use: "application/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml". You really need that.

And that would need to specify the association between the mime type and the xml scheme element contained in the mime type. That presents a little complexity because, based on the examples you have, one top level xml element for both mime types. I guess you can do that if you explain it well enough, though IMO it would make more sense to dispense with <comm-div-info>, and use <comm-div-subs-info> as the top level element of "application/comm-div-info-filter+xml", and <comm-div-ntfy-info> as the top level element of "application/comm-div-info-ntfy+xml"

I think this document also requires a review by a MIME expert before it can be approved.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 May 2012 10:25:56 -0400

> Yes I agree with you that we need to register the 2 XML body types - application/comm-div-info-ntfy+xml" and "application/comm-div-info-filter+xml as MIME type registrations.  Sorry we missed that.

OK.

As things stand I presume you would define them both as requiring the 
content to conform to the schema for <comm-div-info>. But IIUC there is 
a further restriction - that application/comm-div-info-ntfy+xml must match

    <comm-div-info>
      <comm-div-ntfy-info>
        ...
      </comm-div-ntfy-info>
    </comm-div-info>

and application/comm-div-info-filter+xml must match

    <comm-div-info>
      <comm-div-subs-info>
        ...
      </comm-div-subs-info>
    </comm-div-info>

But if that is so, it seems that <comm-div-info> serves no purpose at 
all. It would be simpler, clearer, and a tiny bit smaller to dispense 
with it and just have application/comm-div-info-ntfy+xml conform to 
<comm-div-ntfy-info>, and application/comm-div-info-filter+xml conform 
to <comm-div-subs-info>.

> <Ranjit>  FSM is actually associated with the call diversion service and not with the subscriber / subscription.  The state changes and notifications being sent or not depend on subscription. For e…

We have had a long running conversation over the versions regarding the 
state model. Your comment here reopens that discussion.

I asked the question because of the text at the beginning of 6.11:

    An FSM associated with the subscriber is created in the "IDLE" state,
    e.g. upon receiving filter criteria.

It says that an FSM is associated with a subscriber. If that isn't what 
you mean, then you should write down what you do mean.

	Thanks,
	Paul

> And that would need to specify the association between the mime type and the xml scheme element contained in the mime type. That presents a little complexity because, based on the examples you have, one top level xml element for both mime types. I guess you can do that if you explain it well enough, though IMO it would make more sense to dispense with<comm-div-info>, and use<comm-div-subs-info>  as the top level element of "application/comm-div-info-filter+xml", and<comm-div-ntfy-info>  as the top level element of "application/comm-div-info-ntfy+xml"
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 31 May 2012 08:10:56 -0600

It's  more than just the abstract - the draft clearly says this is not for internet. Given the CDIV is a widely deployed feature, I think anything the IETF publishes for this should be generally applicable for any SIP device. I can't see anything in here that would cause this to only work on IMS / TISPAN. Could all mention of that be removed from the draft and it just defined as a general service?