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

From: Robert Sparks <[email-masked]>
Date: Mon, 08 Sep 2014 15:40:36 -0500

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-sparks-sipcore-refer-explicit-subscription-01.txt
Date: 	Mon, 08 Sep 2014 13:31:32 -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-01.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	01
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-09-08
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-01.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-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-01

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: Ivo Sedlacek <[email-masked]>
Date: Tue, 9 Sep 2014 08:41:39 +0000

Hello Robert,

I reviewed the paper and found the following:

ISSUE 1: the draft states:
-------------------
Sending a REFER within a dialog established
   by an INVITE results in dialog reuse and the associated problems
   described in [RFC5057<http://tools.ietf.org/html/rfc5057>].
-------------------
However, sending of the REFER alone does not result to dialog reuse. The reuse happens only if the refer subscription is created (which is not always the case).

PROPOSAL 1: use the following wording:
-------------------
Acceptance of a REFER request received within a dialog established
   by an INVITE and creation of refer subscription results in dialog reuse and the associated problems
   described in [RFC5057<http://tools.ietf.org/html/rfc5057>].
-------------------

ISSUE 2: the draft states:
-----------
Call
   transfer, as defined in [RFC5589<http://tools.ietf.org/html/rfc5589>], thus requires sending a REFER
   request on a new dialog, associating it with an existing dialog using
   the 'Target-Dialog' mechanism defined in [RFC4538<http://tools.ietf.org/html/rfc4538>].
-----------
However, RFC5589 only recommends it, not requires it. RFC5589 states:
-----------
   As a result, if the Transferee supports the target-dialog extension
   and the Transferor knows the Contact URI is routable outside the
   dialog, the REFER SHOULD be sent in a new dialog.
-----------

PROPOSAL 2: use the following wording:
-------------------
Call
   transfer, as defined in [RFC5589<http://tools.ietf.org/html/rfc5589>], thus recommends sending a REFER
   request on a new dialog, associating it with an existing dialog using
   the 'Target-Dialog' mechanism defined in [RFC4538<http://tools.ietf.org/html/rfc4538>].
-------------------

ISSUE 3: There are situations when neither UAS nor UAC want the refer subscription - see RFC4488. However, the draft mandates the UAS to be ready to create the subscription even if neither UAC nor UAS are interested in it. That's unnecessary.

PROPOSAL 3: If Supported or Require header field with norefersub option tag is indicated in the REFER request, the UAS does not include the Refer-Events-At in 2xx response to REFER request.

ISSUE 4: the draft states:
-----------

A UA MUST NOT include the 'explicitsub' option tag

   in the Require header field of any SIP response other than a 421

   response to a REFER request.
-----------
- this conflicts with RFC3261 stating:
-----------
   Any extensions applied to a non-421 response MUST be listed in a
   Require header field included in the response.
-----------
I.e. Require: explicitsub should be also allowed at least in 2xx responses to REFER request.

PROPOSAL 4: use the following wording:
-------------------

A UA MUST NOT include the 'explicitsub' option tag

   in the Require header field of any SIP response other than a

   response to a REFER request.
-------------------

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 8. září 2014 22:41
To: [email-masked]
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt

-------- Forwarded Message --------
Subject:

New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt

Date:

Mon, 08 Sep 2014 13:31:32 -0700

From:

[email-masked]<mailto:[email-masked]>

To:

Robert Sparks <[email-masked]><mailto:[email-masked]>, Robert Sparks <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:      01

Pages:         11

Abstract:

The IETF Secretariat

---

From: Robert Sparks <[email-masked]>
Date: Tue, 09 Sep 2014 08:56:43 -0500

Thanks for the comments!

On 9/9/14 3:41 AM, Ivo Sedlacek wrote:
>    described in [RFC5057 <http://tools.ietf.org/html/rfc5057>].
>
> -------------------
>
> However, sending of the REFER alone does not result to dialog reuse. 
> The reuse happens only if the refer subscription is created (which is 
> not always the case).
>
>    described in [RFC5057 <http://tools.ietf.org/html/rfc5057>].
>
This bit of wordsmithing is not helping with clarity here. Accounting 
for the one case were you can ask (but not be guaranteed) to suppress 
the subscription doesn't help this document.
>    transfer, as defined in [RFC5589 
> <http://tools.ietf.org/html/rfc5589>], thus requires sending a REFER
>
>    transfer, as defined in [RFC5589 
> <http://tools.ietf.org/html/rfc5589>], thus recommends sending a REFER
>
> ISSUE 3: There are situations when neither UAS nor UAC want the refer 
> subscription - see RFC4488. However, the draft mandates the UAS to be 
> ready to create the subscription even if neither UAC nor UAS are 
> interested in it. That's unnecessary.
>
We talked about providing a way for the UAC to say "and I'm never going 
to subscribe" at IETF90 (see slide 6 from the deck on this topic).
The mechanism discussed there was adding an additional "nosub" tag for 
the client to use instead of "explicitsub" when it knows it doesn't care 
about the subscription. I didn't get the proposal there into this 
version of the draft - I'll get it into the next.
>
> PROPOSAL 3: If Supported or Require header field with norefersub 
> option tag is indicated in the REFER request, the UAS does not include 
> the Refer-Events-At in 2xx response to REFER request.
>
Conflating this mechanism with 4488 is an anti-goal for me.
> ISSUE 4: the draft states:
I'll reply to this one separately.
> This Communication is Confidential. We only send and receive email on 
> the basis of the terms set out at www.ericsson.com/email_disclaimer 
> <http://www.ericsson.com/email_disclaimer>
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Robert 
> Sparks
> *Sent:* 8. září 2014 22:41
> *To:* [email-masked]
> *Subject:* [sipcore] Fwd: New Version Notification for 
> *Subject: *
> New Version Notification for 
> *Date: *
> *From: *
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Robert Sparks <[email-masked]> <mailto:[email-masked]>, 
> Robert Sparks <[email-masked]> <mailto:[email-masked]>
>
> URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-01.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-01
> Diff:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-01
>   
> Abstract:

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 11 Sep 2014 07:53:35 +0000

Hello,

> >    described in [RFC5057].
 > > 
> >    described in [RFC5057].

> This bit of wordsmithing is not helping with clarity here. Accounting for the one case were you can ask (but not be guaranteed) to suppress the subscription doesn't help this document.

Other possible wording of PROPOSAL  1 is:
-------------------
Sending a REFER within a dialog established
   by an INVITE *might* result in dialog reuse and the associated problems
   described in [RFC5057].
-------------------

Would that be better?

> >    transfer, as defined in [RFC5589], thus requires sending a REFER
> >    the 'Target-Dialog' mechanism defined in [RFC4538].
> > -----------
 > > 
> >    transfer, as defined in [RFC5589], thus recommends sending a REFER
> >    the 'Target-Dialog' mechanism defined in [RFC4538].
> > -------------------
 
Any view on this issue and proposal?

> We talked about providing a way for the UAC to say "and I'm never going to subscribe" at IETF90 (see slide 6 from the deck on this topic).
> The mechanism discussed there was adding an additional "nosub" tag for the client to use instead of "explicitsub" when it knows it doesn't care about the subscription. I didn't get the proposal there into this version of the draft - I'll get it into the next.

Thanks, I am looking forward to seeing next version with the "nosub" tag.

> I'll reply to this one separately.

OK

Kind regards
 
Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Sep 2014 11:25:20 +0000

Hi,

Eventhough there are still comments to be addressed, nobody has objected to the mechanism as such. I think we should adopt the draft as the base for a WG delivery. I see no need to wait until Hawaii for that. Let's spend the face-to-face time to discuss issues etc instead.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 11. syyskuuta 2014 10:54
To: Robert Sparks; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt

Hello,

 > > 

Would that be better?

 > > 

OK

Kind regards
 
Ivo Sedlacek
 
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore