Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Jul 2014 18:23:46 -0400

This fixed the missing slide 3 text.

RjS

-------- Original Message --------
Subject: 	New Version Notification for 
draft-sparks-sipcore-refer-clarifications-02.txt
Date: 	Mon, 21 Jul 2014 15:22:39 -0700
From: 	[email-masked]
To: 	Robert Sparks <[email-masked]>, "Adam Roach" <[email-masked]>, 
Adam Roach <[email-masked]>, "Robert Sparks" <[email-masked]>

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

Name:		draft-sparks-sipcore-refer-clarifications
Revision:	02
Title:		Clarifications for the use of REFER with RFC6665
Document date:	2014-07-21
Group:		Individual Submission
Pages:		4
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-02.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-02

Abstract:
    An accepted SIP REFER method creates an implicit subscription using
    the SIP-Specific Event Notification Framework.  That framework was
    revised by RFC6665.  This document highlights the implications of the
    requirement changes in RFC6665, and updates the definition of the
    REFER method, RFC3515, to clarify and disambiguate the impact of
    those changes.

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: Thu, 24 Jul 2014 10:50:07 +0000

Hello,

ISSUE:

section 4 states:
------------------------
4.  Dialog reuse is prohibited

   As a direct consequence of requiring the use of GRUU, and the
  requirements in section 4.5.2 of RFC6665, sending a REFER that might
   result in an additional dialog usage within any existing dialog is
   prohibited.

   >>>A user agent constructing a REFER request MUST built it as an out-of-
   dialog message as defined in [RFC3261].<<<  Thus, the REFER request will
   have no tag parameter in its To: header field.

   A user agent wishing to identify an existing dialog (such as for call
   transfer as defined in [RFC5589] MUST use the "Target-Dialog"
   extension defined in [RFC4538] to do so.

   >>>If a user agent can be certain that no implicit subscription will be
   created as a result of sending a REFER request (such as by requiring
   an extension that disallows any such subscription), the REFER request
   MAY be sent within an existing dialog.<<<  Such a REFER will be
   constructed with its Contact header field populated with the dialog's
   Local URI as specified in section 12 of [RFC3261].
------------------------

2nd paragraph of the section 4 states unconditional UA procedure (MUST built it as an out-of-dialog message).
4th paragraph of the section 4 states an option for the UA (If a user agent can be certain ...., the REFER request MAY be sent within an existing dialog).

It is not possible to create a UA which would use the option described in 4th paragraph and still be compliant to the statement in 2nd paragraph.

PROPOSAL:

The 2nd paragraph should be conditioned by a condition opposite to the one in the 4th paragraph.

I.e. 2nd paragraph should be conditioned by "Unless a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription),"

Kind regards

Ivo Sedlacek

From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 22. července 2014 0:24
To: [email-masked]
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

RjS

-------- Original Message --------
Subject:

New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Date:

Mon, 21 Jul 2014 15:22:39 -0700

From:

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

To:

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

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 24 Jul 2014 11:36:00 +0000

We require GRUU, to which I have never seen in the field ( deployments)...mmmm

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]<mailto:[email-masked]>

On Jul 24, 2014, at 6:50 AM, "Ivo Sedlacek" <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 22. července 2014 0:24
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Robert Sparks <[email-masked]>
Date: Thu, 24 Jul 2014 17:35:57 -0400

Yes - thanks for the catch, and sorry for not tweaking that already 
(should have waited until next week).
I'll send an update soon.

RjS
On 7/24/14, 6:50 AM, Ivo Sedlacek wrote:
> _   >>>A user agent constructing a REFER request MUST built it as an 
> out-of-_
>
> _dialog message as defined in [RFC3261].<<< _ Thus, the REFER request will
>
> _   >>>If a user agent can be certain that no implicit subscription 
> will be_
>
> _created as a result of sending a REFER request (such as by requiring_
>
> _an extension that disallows any such subscription), the REFER request_
>
> _MAY be sent within an existing dialog.<<<_Such a REFER will be
>
> 4th paragraph of the section 4 states an option for the UA (If a user 
> agent can be certain ...., the REFER request MAY be sent within an 
> existing dialog).
>
> It is not possible to create a UA which would use the option described 
> in 4th paragraph and still be compliant to the statement in 2nd paragraph.
>
> PROPOSAL:
>
> I.e. 2nd paragraph should be conditioned by "Unless a user agent can 
> be certain that no implicit subscription will be created as a result 
> of sending a REFER request (such as by requiring an extension that 
> disallows any such subscription),"
>
> Kind regards
>
> Ivo Sedlacek
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Robert 
> Sparks
> *Sent:* 22. července 2014 0:24
> *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]>, "Adam Roach" 
> <[email-masked]> <mailto:[email-masked]>, Adam Roach 
> <[email-masked]> <mailto:[email-masked]>, "Robert Sparks" 
> <[email-masked]> <mailto:[email-masked]>
>
> URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-02.txt
> Status:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/
> Htmlized:http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-02
> Diff:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-02
>   
> Abstract:

---

From: Robert Sparks <[email-masked]>
Date: Thu, 24 Jul 2014 17:38:41 -0400

To be clear, this document points out that the currently published RFCs 
require GRUU in these situations.
The refer-explicitsub document provides a way to relax that.

RjS

On 7/24/14, 7:36 AM, DOLLY, MARTIN C wrote:
> [email-masked] <mailto:[email-masked]>
>
> On Jul 24, 2014, at 6:50 AM, "Ivo Sedlacek" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hello,
>>
>> ISSUE:
>>
>> section 4 states:
>>
>> ------------------------
>>
>> 2nd paragraph of the section 4 states unconditional UA procedure 
>> (MUST built it as an out-of-dialog message).
>>
>> It is not possible to create a UA which would use the option 
>> described in 4th paragraph and still be compliant to the statement in 
>> 2nd paragraph.
>>
>> PROPOSAL:
>>
>> *From:*sipcore [mailto:[email-masked]] *On Behalf Of 
>> *Robert Sparks
>> *To:* [email-masked] <mailto:[email-masked]>
>> Robert Sparks <[email-masked]> <mailto:[email-masked]>, "Adam 
>> Roach" <[email-masked]> <mailto:[email-masked]>, Adam Roach 
>> until the htmlized version and diff are available attools.ietf.org  <http://tools.ietf.org>.
>>   
>> The IETF Secretariat
>>   
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 25 Jul 2014 06:48:53 +0000

Thank you for taking my comment into account.

I identified one more issue:

ISSUE 2:

section 3 states:
------------------------
   A UA that supports receiving REFER needs to include a GRUU as a
   Contact in INVITE requests to ensure out-of-dialog REFER requests
   related to this dialog arrive at this UA.
------------------------

The above requirement is unnecessary in case the UA supports receiving only REFER requests sent within an existing dialog, for which the UA is certain that no implicit subscription will be created.

Moreover, the 2nd part of the sentence discusses "out-of-dialog REFER requests related to this dialog" while 1st part discusses just "REFER".

PROPOSAL 2:

The requirement should be modified e.g. as follows:

------------------------
   A UA that supports receiving an out-of-dialog REFER request related to a dialog created by an INVITE request needs to include a GRUU as a
   Contact in the INVITE request to ensure any out-of-dialog REFER requests
   related to a dialog created by the INVITE request arrive at this UA.
------------------------

Kind regards

Ivo Sedlacek

From: Robert Sparks [mailto:[email-masked]]
Sent: 24. července 2014 23:36
To: Ivo Sedlacek; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Yes - thanks for the catch, and sorry for not tweaking that already (should have waited until next week).
I'll send an update soon.

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Andrew Allen <[email-masked]>
Date: Fri, 25 Jul 2014 13:38:39 +0000

I disagree with this new proposal

How can a UA that acts as a UAS for REFER know that all UACs will request not to create a subscription?

According to RFC 3515

2.4.4 Using SIP Events to Report the Results of the Reference

                The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference.

Therefore the ability to create an implicit subscription when accepting a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all UACs

So any UA that supports receiving REFER request MUST be ready to create a subscription and therefore MUST provide a GRUU as a Contact in INVITE requests to ensure that out-of-dialog REFER requests can be sent.

Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: Friday, July 25, 2014 2:49 AM
To: Robert Sparks; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

From: Robert Sparks [mailto:[email-masked]]
Sent: 24. července 2014 23:36
To: Ivo Sedlacek; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Andrew Allen <[email-masked]>
Date: Fri, 25 Jul 2014 14:05:28 +0000

Robert

I have reviewed the new version and my comment is addressed now.

Another issue though. In a discussion taking place on another SDO list some people are still taking the view that if they have defined a feature at both the UAC and UAS with a media feature tag that lets the UAC know the UAS supports the feature and the feature defines that the UAC will use norefersub to request that a subscription is not created by REFER and the UAS will accept the norefersub and not create a subscription then it’s OK to then send the REFER on an existing dialog.

My view is this is a violation of protocol layering principles and could cause problems for implementations since SIP protocol layer functionality is now be coupled with the application semantics (i.e ths protocol layer has to know what the application behavior is going to be in order to know that no subscription will be created and therefore its OK to send the REFER on the pre-existing dialog).

We need the refer-explicit-subscription mechanism in order to ensure that no implicit subscription is created.

I welcome opinions on this?

Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Monday, July 21, 2014 6:24 PM
To: [email-masked]
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 25 Jul 2014 15:28:29 +0000

Hello Andrew,

> How can a UA that acts as a UAS for REFER know that all UACs will request not to create a subscription?

One possibility is e.g. the UA that acts as a UAS for REFER has a local policy to accept only the REFER requests with Require: explicitsub sent as in-dialog requests, and to include a Refer-Events-At header field with URI with .invalid hostname in 2xx response to REFER request.

Kind regards

Ivo Sedlacek

From: Andrew Allen [mailto:[email-masked]]
Sent: 25. července 2014 15:39
To: Ivo Sedlacek; Robert Sparks; [email-masked]
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

According to RFC 3515

Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: Friday, July 25, 2014 2:49 AM
To: Robert Sparks; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Andrew Allen <[email-masked]>
Date: Fri, 25 Jul 2014 15:30:31 +0000

This is just not RFC 3515. You don’t get to pick and choose which bits of mandatory behavior that you implement and still claim to be compliant

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Friday, July 25, 2014 11:28 AM
To: Andrew Allen; Robert Sparks; [email-masked]
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Hello Andrew,

Kind regards

Ivo Sedlacek

From: Andrew Allen [mailto:[email-masked]]
Sent: 25. července 2014 15:39
To: Ivo Sedlacek; Robert Sparks; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

According to RFC 3515

Andrew

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 25 Jul 2014 15:35:36 +0000

Hello Andrew,

you asked for a use case where a UA that acts as a UAS for REFER know that all UACs will request not to create a subscription

I gave you a use case. It might not be a frequent one but there is nothing precluding such usage.

Why do you believe such use case is prohibited?

Kind regards

Ivo Sedlacek

From: Andrew Allen [mailto:[email-masked]]
Sent: 25. července 2014 17:31
To: Ivo Sedlacek; Robert Sparks; [email-masked]
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Friday, July 25, 2014 11:28 AM
To: Andrew Allen; Robert Sparks; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Hello Andrew,

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Andrew Allen <[email-masked]>
Date: Fri, 25 Jul 2014 16:17:23 +0000

So basically you are arguing you can have a policy not to fully implement the RFC and thus cause inteoperability problems rather than solve them.

While in some specific 3GPP cases it might work for now if you didn't fullly implement REFER according to RFC 3515 but only the bits you thought you needed what happens if later we decide we do need a notification - then we have a backward compatibility problem!

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Friday, July 25, 2014 11:35 AM Eastern Standard Time
To: Andrew Allen; Robert Sparks <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Hello Andrew,

Kind regards

Ivo Sedlacek

Hello Andrew,

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 26 Jul 2014 00:18:49 +0000

Andrew,

We discussed your “other issue” in London, and it was clear that there were different opinions.

A way to solve that is to use Robert’s explicitsub mechanism. It allows the UAC to ensure that no implicit subscription will be created – without having to rely on media feature tags etc.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 25 July 2014 17:05
To: Robert Sparks; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Robert

Andrew

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Andrew Allen <[email-masked]>
Date: Sun, 27 Jul 2014 18:36:02 +0000

I support the progression of the explicit subscription mechanism. Its probably what we should have done in the first place.

I still have to do a proper review of that draft but hope to provide a full list of comments soon.

However that is an extension - we still will need to support RFC 3515 mandatory behavior and the RFC 6665 update to it.

My comments about policy still stand - the policy should be a matter for the user not a matter of partial implementation. All implementations compliant with RFC 3515 need to support Refer events whether they think they need them or not.

Andrew

From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, July 25, 2014 08:18 PM Eastern Standard Time
To: Andrew Allen; Robert Sparks <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Andrew,

Regards,

Christer

Robert

Andrew

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 28 Jul 2014 06:06:44 +0000

> So basically you are arguing you can have a policy not to fully implement the RFC and thus cause inteoperability problems rather than solve them.

No.

I am arguing that a UA can implement the entire RFC3515, and, for a given dialog, have a local policy to use the RFC3515 only together with draft-sparks-sipcore-refer-explicit-subscription (i.e. REFER contains Require: explicitsub) and without providing subscription to refer event package (2xx to REFER contains Refer-Events-At header field with URI with .invalid hostname).

Since there is no need to send out-of-dialog REFER or out-of-dialog SUBSCRIBE to such UA in relation to such dialog (such REFER or SUBSCRIBE would be rejected), the GRUU in Contact of INVITE request does not provide any value.

Can you please explain where you see the non-fully-implemented-RFC implementation in such case?

Kind regards

Ivo Sedlacek

From: Andrew Allen [mailto:[email-masked]]
Sent: 25. července 2014 18:17
To: Ivo Sedlacek; [email-masked]; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Friday, July 25, 2014 11:35 AM Eastern Standard Time
To: Andrew Allen; Robert Sparks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Hello Andrew,

Kind regards

Ivo Sedlacek

Hello Andrew,

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Jul 2014 13:36:32 -0500

On 7/25/14, 10:28 AM, Ivo Sedlacek wrote:
> One possibility is e.g. the UA that acts as a UAS for REFER has a 
> local policy to accept only the REFER requests with Require: 
> explicitsub sent as in-dialog requests, and to include a 
> Refer-Events-At header field with URI with .invalid hostname in 2xx 
> response to REFER request.
>
As I indicated in the slides, the next version of the explicitsub 
document will also define a nosub option tag for this case.
>
> Kind regards
>
> Ivo Sedlacek
>
> *From:*Andrew Allen [mailto:[email-masked]]
> *Sent:* 25. července 2014 15:39
> *To:* Ivo Sedlacek; Robert Sparks; [email-masked]
> *Subject:* RE: [sipcore] Fwd: New Version Notification for 
>              The NOTIFY mechanism defined in [2] MUST be used to 
> inform the agent sending the REFER of the status of the reference.
>
> Therefore the ability to create an implicit subscription when 
> accepting a REFER is mandatory behavior in RFC 3515 and is expected to 
> be supported by all UACs
>
> So any UA that supports receiving REFER request MUST be ready to 
> create a subscription and therefore MUST provide a GRUU as a Contact 
> in INVITE requests to ensure that out-of-dialog REFER requests can be 
> sent.
>
> Andrew
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Ivo 
> Sedlacek
> *Sent:* Friday, July 25, 2014 2:49 AM
> *To:* Robert Sparks; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sipcore] Fwd: New Version Notification for 
> The above requirement is unnecessary in case the UA supports receiving 
> only REFER requests sent within an existing dialog, for which the UA 
> is certain that no implicit subscription will be created.
>
> Moreover, the 2nd part of the sentence discusses "out-of-dialog REFER 
> requests related to this dialog" while 1st part discusses just "REFER".
>
> PROPOSAL 2:
>
> A UA that supports receiving _an out-of-dialog_ REFER _request related 
> to a dialog created by an INVITE request_ needs to include a GRUU as a
>
> related to _a_ dialog_created by the INVITE request_ arrive at this UA.
>
> ------------------------
>
> Kind regards
>
> Ivo Sedlacek
>
> *From:*Robert Sparks [mailto:[email-masked]]
> *Sent:* 24. července 2014 23:36
> *To:* Ivo Sedlacek; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sipcore] Fwd: New Version Notification for 
>     _   >>>A user agent constructing a REFER request MUST built it as
>     an out-of-_
>
>     _   >>>If a user agent can be certain that no implicit
>     subscription will be_
>
>     4th paragraph of the section 4 states an option for the UA (If a
>     user agent can be certain ...., the REFER request MAY be sent
>     within an existing dialog).
>
>     described in 4th paragraph and still be compliant to the statement
>     in 2nd paragraph.
>
>     PROPOSAL:
>
>     I.e. 2nd paragraph should be conditioned by "Unless a user agent
>     can be certain that no implicit subscription will be created as a
>     result of sending a REFER request (such as by requiring an
>     extension that disallows any such subscription),"
>
>     Kind regards
>
>     Ivo Sedlacek
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Jul 2014 09:58:47 +0000

Hi Robert,

If I understood the nosub option tag proposal correctly, it is a way for the sender of the REFER request to indicate that it will not create a subscription.

What I think Ivo is talking about is a way for the receiver of the INVITE request to tell the sender not to bother sending an out-of-dialog REFER request to begin with.

Regards,

Christer

________________________________
From: sipcore [[email-masked]] on behalf of Robert Sparks [[email-masked]]
Sent: Monday, 28 July 2014 9:36 PM
To: Ivo Sedlacek; Andrew Allen; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

One possibility is e.g. the UA that acts as a UAS for REFER has a local policy to accept only the REFER requests with Require: explicitsub sent as in-dialog requests, and to include a Refer-Events-At header field with URI with .invalid hostname in 2xx response to REFER request.
As I indicated in the slides, the next version of the explicitsub document will also define a nosub option tag for this case.

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

ISSUE 2:

section 3 states:
------------------------

PROPOSAL 2:

------------------------

Kind regards

Ivo Sedlacek

RjS

ISSUE:

section 4 states:
------------------------

PROPOSAL:

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      02

Pages:         4

Abstract:

   those changes.

The IETF Secretariat