Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Jun 2014 16:34:22 -0500

The other idea we started discussing in London:

-------- Original Message --------
Subject: 	New Version Notification for 
draft-sparks-sipcore-refer-explicit-subscription-00.txt
Date: 	Tue, 17 Jun 2014 14:27:48 -0700
From: 	[email-masked]
To: 	Robert Sparks <[email-masked]>, "Robert Sparks" <[email-masked]>

A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-00.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	00
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-06-17
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-00

Abstract:
    The SIP REFER request, as defined by RFC3515, triggers an implicit
    SIP-Specific Event Notification framework subscription.  Conflating
    the start of the subscription with handling the REFER request makes
    negotiating SUBSCRIBE extensions impossible, and complicates avoiding
    SIP dialog sharing.  This document defines an extension to REFER to
    remove the implicit subscription and replace it with an explicit one.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Jun 2014 08:34:33 +0000

Hi,

I assume the semantics of the suggested new 'explicitsub' option tag would be "MUST SUPPORT *AND* MUST USE".

(I.e. the option tag can be used to ensure that the receiver will not create a subscription, instead of simply making sure the receiver understands the meaning of, and supports the mechanism associated with, the option-tag?)

Regards,

Christer

________________________________
From: sipcore [[email-masked]] on behalf of Robert Sparks [[email-masked]]
Sent: Wednesday, 18 June 2014 12:34 AM
To: [email-masked]
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt

-------- Original Message --------
Subject:        New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt
Date:   Tue, 17 Jun 2014 14:27:48 -0700
From:   [email-masked]<mailto:[email-masked]>
To:     Robert Sparks <[email-masked]><mailto:[email-masked]>, "Robert Sparks" <[email-masked]><mailto:[email-masked]>

Abstract:

The IETF Secretariat

---

From: Robert Sparks <[email-masked]>
Date: Wed, 25 Jun 2014 12:00:17 -0500

Hi Christer - sorry for the lag in the response here.

On 6/20/14, 3:34 AM, Christer Holmberg wrote:
> Hi,
> I assume the semantics of the suggested new 'explicitsub' option 
> tag would be "MUST SUPPORT *AND* MUST USE".
> (I.e. the option tag can be used to ensure that the receiver will not 
> create a subscription, instead of simply making sure the receiver 
> understands the meaning of, and supports the mechanism associated 
> with, the option-tag?)
Yes, that's right.
> Regards,
> Christer
> ------------------------------------------------------------------------
> *From:* sipcore [[email-masked]] on behalf of Robert Sparks 
> [[email-masked]]
> *Sent:* Wednesday, 18 June 2014 12:34 AM
> *To:* [email-masked]
> *Subject:* [sipcore] Fwd: New Version Notification for 
> URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-00.txt
> Status:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/
> Htmlized:http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-00
>
>
> Abstract:

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Jun 2014 10:50:26 +0000

Hi,

>>(I.e. the option tag can be used to ensure that the receiver will not create a subscription, instead of simply making sure the receiver understands the meaning of, and supports the mechanism associ…
Thanks for the clarification! I think we need to make that very clear in the draft, to avoid confusion in the future :)
So, I think this extension would be useful.

Regards,

Christer

-------- Original Message -------- Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-00.txt
Date: Tue, 17 Jun 2014 14:27:48 -0700
From: [email-masked]
To: Robert Sparks <[email-masked]>, "Robert Sparks" <[email-masked]>

Abstract:

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 10:58:31 -0400

Robert,

Thanks for doing this. I think it suggests an approach that could meet 
most or all of the concerns that people have with the current mechanisms.

Regarding 5.4 (Could this deprecate RFC4488):

This section discusses what a server can do if it doesn't wish to 
provide a subscription. But 4488 is about what a client should do if it 
doesn't want a subscription.

This new draft satisfies the client needs *without* section 5.4.

The mechanism you mention in 5.4 satisfies a new need.

Now consider one more thing: suppose the client wants to do the refer in 
dialog, and has no intention of establishing a subscription. So he 
doesn't care what the returned Refer-Events-At URI is. Potentially this 
costs the server some resources, to be prepared to receive the 
subscription request that will never be coming. If the client had a way 
to say that no subscription will be coming, then that would allow the 
server to avoid the cost.

So it would be helpful to have a mechanism to indicate that it doesn't 
want an implicit subscription and also doesn't need any way to establish 
an explicit subscription.

The new mechanisms from this draft could be combined with those from 
4488 to accomplish this. E.g.,

	Require: explicitsub
	Refer-Sub: false

Alternatively we could define a new way to signal this.

Otherwise this draft seems good.

	Thanks,
	Paul

On 6/17/14 5:34 PM, Robert Sparks wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>