Subject: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking

From: [email-masked]
Date: Mon, 11 Oct 2010 10:16:38 +0800

In our implementation(the background system is IMS) of this draft, we find 
one problem about forking.

In section 6.9(Handling of Forked Requests) of this draft:

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.

we could find that forked subscription is forbidden for this Event 
package.

While in real IMS network, there are cases the div-services are deployed 
in different ASs. Then, the subscription should be forked to the different 
ASs, if there are more than one AS do div-services for the specific 
service user.

We once considered one way to avoid the forking condition. The way is to 
let the user send different subscription for different div-service. But by 
the end user's viewpoint, he/she have no idea of the deployment of the 
div-servies(in ASs). So, he/she does't know when should he/she send 
separated subscription or not. 

So, I suggest to allow forking for this Event package.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 12 Oct 2010 19:51:10 +0800

Hi

Yes we did not want to support forking for the CDIV package since the
CDIV notification is only intended for the subscriber who subscribed it
. 

Regards

Ranjit

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 11, 2010 7:47 AM
To: [email-masked]
Cc: Avasarala Ranjit-A20990; [email-masked]; [email-masked]
Subject: Comments on draft-avasarala-dispatch-comm-div-notification-05
//About forking

In our implementation(the background system is IMS) of this draft, we
find one problem about forking. 

While in real IMS network, there are cases the div-services are deployed
in different ASs. Then, the subscription should be forked to the
different ASs, if there are more than one AS do div-services for the
specific service user. 

We once considered one way to avoid the forking condition. The way is to
let the user send different subscription for different div-service. But
by the end user's viewpoint, he/she have no idea of the deployment of
the div-servies(in ASs). So, he/she does't know when should he/she send
separated subscription or not.   

Thanks, 

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain
secrecy and are not permitted to disclose the contents of this
communication to others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.

---

From: [email-masked]
Date: Tue, 12 Oct 2010 20:59:31 +0800

Hi Ranjit,

I'd like to point out I had offered one real requirement about supporting 
forking for this Event package. IMO, it is reasonable to supporting 
forking here.

Thanks,

Gao

"Avasarala Ranjit-A20990" <[email-masked]> 
2010-10-12 19:51

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: Comments on draft-avasarala-dispatch-comm-div-notification-05  //About 
forking

Hi
 
Yes we did not want to support forking for the CDIV package since the CDIV 
notification is only intended for the subscriber who subscribed it . 
 
Regards
Ranjit

Thanks, 

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Oct 2010 11:05:19 -0500

Ranjit:

I would strongly suggest that you adopt Gao's proposal to allow multiple 
subscriptions to result from a fork.

The more event packages are defined, the more I think that any package 
that specifies that only one subscription can be established as the 
result of forking simply reflects a lack of imagination on the part of 
the draft author.

For example: the registration event package in RFC 3680 also chose to 
specify that only one subscription can be established. The explanation 
(in section 4.9) literally evaluates to "we can't imagine why this might 
be useful, so we're going to prevent it."

Fast-forward 4 years. We're doing work in MARTINI that is predicated on 
a network in which multiple registrars for an AOR are possible. We're 
having to update RFC3680 in the solution document to say, "whoops, that 
was wrong, we really do need multiple subscriptions sometimes."

I think RFC 3265 actually got this wrong. The suggestion that whole 
classes of events never make sense in the context of forking is looking 
increasingly like a failure to envision novel uses of the protocol. And, 
in fact, with GRUUs, it's no longer necessary to even have this kind of 
behavior. If a user doesn't want a SUBSCRIBE to fork, they use a GRUU.

In particular, since Gao has apparently identified a system right now 
that would benefit from multiple subscriptions, it doesn't even require 
that much imagination to forsee a system that might require this.

/a

On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote:
> CDIV notification is only intended for the subscriber who subscribed it .
>
> Regards
>
> Ranjit
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Monday, October 11, 2010 7:47 AM
> *To:* [email-masked]
> *Cc:* Avasarala Ranjit-A20990; [email-masked]; [email-masked]
> *Subject:* Comments on 
> draft-avasarala-dispatch-comm-div-notification-05 //About forking
>
>
> While in real IMS network, there are cases the div-services are 
> deployed in different ASs. Then, the subscription should be forked to 
> the different ASs, if there are more than one AS do div-services for 
> the specific service user.
>
> We once considered one way to avoid the forking condition. The way is 
> to let the user send different subscription for different div-service. 
> But by the end user's viewpoint, he/she have no idea of the deployment 
> of the div-servies(in ASs). So, he/she does't know when should he/she 
> send separated subscription or not.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 13 Oct 2010 12:20:06 +0800

Hi Adam

So will RFC 3265 be updated to reflect the change of SUBSCRIBE request
getting forked?

Regards

Ranjit

From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2010 9:35 PM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Comments on
draft-avasarala-dispatch-comm-div-notification-05 //About forking

Ranjit:

/a

Hi

Regards

Ranjit

Thanks, 

Gao

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Oct 2010 23:27:55 -0500

The 3265bis document already requires the use of GRUUs. I'm going to 
look carefully at the section regarding forking to see what reasonable 
changes we can make there to prevent this kind of problem in the future.

But, unless you're going to wait for 3265bis to conclude, 
div-notification will be based on 3265. Your best bet is to clearly 
specify that multiple subscriptions may legally be established by a 
single SUBSCRIBE request.

/a

On 10/12/10 23:20, Oct 12, Avasarala Ranjit-A20990 wrote:
> *From:* Adam Roach [mailto:[email-masked]]
> *Sent:* Tuesday, October 12, 2010 9:35 PM
> *To:* Avasarala Ranjit-A20990
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [dispatch] Comments on 
> I would strongly suggest that you adopt Gao's proposal to allow 
> multiple subscriptions to result from a fork.
>
> (in section 4.9) literally evaluates to "we can't imagine why this 
> might be useful, so we're going to prevent it."
>
> Fast-forward 4 years. We're doing work in MARTINI that is predicated 
> on a network in which multiple registrars for an AOR are possible. 
> We're having to update RFC3680 in the solution document to say, 
> "whoops, that was wrong, we really do need multiple subscriptions 
> sometimes."
>
> classes of events never make sense in the context of forking is 
> looking increasingly like a failure to envision novel uses of the 
> protocol. And, in fact, with GRUUs, it's no longer necessary to even 
> have this kind of behavior. If a user doesn't want a SUBSCRIBE to 
> fork, they use a GRUU.
>
> that would benefit from multiple subscriptions, it doesn't even 
> require that much imagination to forsee a system that might require this.
>
> /a
>
> *From:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* Avasarala Ranjit-A20990; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Comments on 
> e_mail : [email-masked] <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>