Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 19 Aug 2014 21:01:55 +0900

Hi,

> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/

I have any questions.

1)
I think that refer subscription should be created before sending REFER with "explicitsub".
If a referee receives SUBSCRIBE after ending of procedure for refer, what does the referee notify?

2)
Does SUBSCRIBE contain Target-Dialog(-like) header?

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2014 14:32:56 -0400

Hi Shinji,

> Does SUBSCRIBE contain Target-Dialog(-like) header?

I think I see your point, but your suggestion presents some difficulties.

What is the target for the subscribe?

In Robert's proposal the refer target returns a uri, which in concept 
identifies the state of the refer. To address your question about this, 
I guess it just maintain sufficient state about the refer to send 
notifications once the subscribe arrives. This may require some buffering.

With your suggestion I guess the subscribe target must be the same as 
the target for the REFER. That requires that such a subscription be 
allowed even though no REFER has been received. And it must be allowed 
from anyone who would be allowed to send a REFER, not just from the 
source that actually sent a refer.

Both ways have problems. Which are worse?

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 20 Aug 2014 11:36:55 +0900

Hi Paul,

Thanks for your reply.
My comment inline.

>identifies the state of the refer. To address your question about this, 

IIUC you say SUBSCRIBE has an refer-id-token that is issued by a referee(notifier).
My cloudy idea is that REFER and SUBSCRIBE have a same subscribe-id-token that is issued by a subscriber or notifier.

>notifications once the subscribe arrives. This may require some buffering.

I've been afraid someone says "buffering".
What does the buffering belong to?
How long is the life of the buffering?
Does the buffering have a state machine?
>From a implementation perspective, it seems to be almost a subscription.

>source that actually sent a refer.

I see the need for an authorization.
It is one of further considerations.

>Both ways have problems. Which are worse?

I only wish not to implement the subscription-like buffer.

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 20 Aug 2014 11:57:03 +0900

Hi Paul,

I just come up with another approach.

A referrer send REFER within an existing dialog.
And a notifier(referee) send NOTIFY within new dialog.
Of course Request URI of NOTIFY is a GRUU of a referrer.

It seems to be a simple solution for an avoidance of dialog-reuse.

I think this option(Required: subscription-newdialog?) is available
for not only REFER but also SUBSCRIBE.

Regards,
Shinji