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

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Jul 2014 17:18:37 -0500

Adam and I spent some time today editing to account for the discussion.
We believe we covered all the concerns raised.

The sentence in section 3 was getting a bit complex, so we split it up 
into several.
Here's what it was before splitting it up:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog 
REFER requests
related to any dialog created by the INVITE arrive at this UA.

You can see what it turned into by looking in the draft.

RjS

-------- Original Message --------
Subject: 	New Version Notification for 
draft-sparks-sipcore-refer-clarifications-03.txt
Date: 	Mon, 28 Jul 2014 15:16:04 -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-03.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

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

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: Tue, 29 Jul 2014 14:52:20 +0000

Hello,

thank you for the updated draft.

Changes in section 4 resolve the first ISSUE I raised. Thank you.

Changes in section 3 are improvement. However, there is one more situation when the draft requires UA to set Contact of INVITE request to GRUU, when the GRUU would actually NOT be needed.

Particularly, if a UA supports receiving and accepting REFER request, the UA can be willing to accept such REFER for some sessions only. E.g. the UA can have two types of sessions:
- Type_A sessions for which the UE is willing to accept corresponding out-of-dialog REFER; and
- Type_B sessions for which the UE is NOT willing to accept corresponding out-of-dialog REFER. Any received out-of-dialog REFER request corresponding to such session would be rejected.

For Type_A sessions, I agree that GRUU (or at least a URI with GRUU properties) in Contact of INVITE is needed.
For Type_B sessions, GRUU in Contact of INVITE is not needed. UA will anyway reject any received out-of-dialog REFER request corresponding to such session.

So, in other words, GRUU in Contact of INVITE is needed only if UA wishes to receive an out-of-dialog REFER and >>is will to accept<< such out-of-dialog REFER.

Thus, the text should state:

   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include
   a GRUU in the Contact header field of >>the<< INVITE request.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs are routed to the correct user agent.  UAs
   that will never create a implicit subscription in response to a REFER
   (that is, those that will reject any REFER that might result in an
   implicit subscription) are exempted from this behavior.

Kind regards

Ivo Sedlacek

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

The sentence in section 3 was getting a bit complex, so we split it up into several.
Here's what it was before splitting it up:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE arrive at this UA.

RjS

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

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

Date:

Mon, 28 Jul 2014 15:16:04 -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:      03

Pages:         4

Abstract:

   those changes.

The IETF Secretariat

---

From: Adam Roach <[email-masked]>
Date: Tue, 29 Jul 2014 10:18:53 -0500

On 7/29/14 09:52, Ivo Sedlacek wrote:
>    In general, UAs that support receiving >>and accepting an 
> out-of-dialog<< REFER request >>corresponding to a dialog established 
> by an INVITE request<< need to include
>

I helped with the phrasing here, and one of the goals here was to make 
the first sentence cover the vast majority of the cases (hence "in 
general"), with the exceptional cases described later. The problem was 
that the overall concept was getting lost in a maze of twisty clauses: 
the clarification had become worse than the source text; it was actually 
more confusing.

Your proposal returns it to this very confusing state, and is way, way 
out into the realm of exceptional cases.

So I'll counterpropose:

    In general, UAs that support receiving REFER requests need to include
    a GRUU in the Contact header field of all INVITE requests.  This
    ensures that out-of-dialog REFER requests corresponding to any
    resulting INVITE dialogs are routed to the correct user agent.  UAs
    that will not create a implicit subscription in response to a REFER
    for the resulting dialog(s) -- that is, those that will reject a
    corresponding REFER that might result in an implicit subscription --
    are exempted from this behavior.

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 30 Jul 2014 12:24:55 +0000

I understand the difficulty in formulation.

Would the following be acceptable?

   that will >>>not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request

   are exempted from including a GRUU in the Contact header field of the INVITE request.<<<

Kind regards

Ivo Sedlacek

From: Adam Roach [mailto:[email-masked]]
Sent: 29. července 2014 17:19
To: Ivo Sedlacek; Robert Sparks; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

I helped with the phrasing here, and one of the goals here was to make the first sentence cover the vast majority of the cases (hence "in general"), with the exceptional cases described later. The problem was that the overall concept was getting lost in a maze of twisty clauses: the clarification had become worse than the source text; it was actually more confusing.

Your proposal returns it to this very confusing state, and is way, way out into the realm of exceptional cases.

So I'll counterpropose:

/a

---

From: Andrew Allen <[email-masked]>
Date: Wed, 30 Jul 2014 15:33:21 +0000

I have a general concern with the direction this is now going.

Are we now saying here that it’s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)?

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 RFC 3515 UACs

I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC.

If so then I think we will need a new sip options tag (e.g REFER-NOSUB) to be used in place of the REFER options tag so that a RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of a REFER and that includes an Accept-Contact request to reach a UA that supports REFER doesn’t end up at a UAS that doesn’t  support compliant RFC 3515 behavior and ends up having its REFER requests rejected.

My own view is that we should keep with the principle of backward compatibility and that even when these no automatic subscription extensions are supported that full support for RFC 3515 behavior is continued.

Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, July 29, 2014 11:19 AM
To: Ivo Sedlacek; Robert Sparks; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

So I'll counterpropose:

/a

---

From: Robert Sparks <[email-masked]>
Date: Wed, 30 Jul 2014 11:53:40 -0500

> I have a general concern with the direction this is now going.
I don't think you have the backwards-compatibility concern quite right, 
but I agree that the current wording isn't there yet.
>
> Are we now saying here that it’s OK for a UA that supports receiving 
> REFER to arbitrarily reject any REFER that would create a subscription 
> (i.e be incompatible with RFC 3515 UACs by basically not supporting 
> RFC 3515 UAS compliant behavior)?
>
No, _this_ document is not defining new behavior. It's only clarifying 
what's already defined.

>              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
>
FWIW, Accepting is the key word here.
>
> a REFER is mandatory behavior in RFC 3515 and is expected to be 
> supported by all RFC 3515 UACs
>
> I think before agreeing any wording here we should have a general 
> discussion on the principle of whether these extensions that allow 
> UACs to request that no implicit subscription can be effectively 
> required by REFER UAS to be supported at the UAC.
>
This, and what you have below, is a discussion we definitely need to 
have as part of the extension document.
It is not necessary to wait for that discussion to complete the 
clarifications document that talks about what the specs say _now_.

My discomfort with the current text is that we've made it complex to 
make it so that we don't have to update the document once the proposed 
extensions exist.
There are NO currently standardized cases where the exemption in the 
current text would be invoked, and I don't think people are trying to 
argue there are - I'm hearing that to get there, they expect to invoke 
the yet-to-be-defined extension.

So, lets go back to the slightly longer sentence that led to this:

In an attempt to be future-proof, that's introducing the potential for 
confusion about what the current standards define.
Let's remove that confusion.
Here's a proposed replacement, taking Adam's sentence simplification 
into account:

    A UA that will accept a REFER request needs to include
    a GRUU in the Contact header field of all INVITE requests.  This
    ensures that out-of-dialog REFER requests corresponding to any
    resulting INVITE dialogs arrive at this UA. Future extensions
    [draft-sparks-sipcore-refer-explicitsub] might relax this requirement
    by defining a REFER request that cannot create an implicit subscription.

Unless I hear objection soon, I'll rev the draft with that content.

> If so then I think we will need a new sip options tag (e.g 
> REFER-NOSUB) to be used in place of the REFER options tag so that a 
> RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of 
> a REFER and that includes an Accept-Contact request to reach a UA that 
> supports REFER doesn’t end up at a UAS that doesn’t  support compliant 
> RFC 3515 behavior and ends up having its REFER requests rejected.
>
> My own view is that we should keep with the principle of backward 
> compatibility and that even when these no automatic subscription 
> extensions are supported that full support for RFC 3515 behavior is 
> continued.
>
> Andrew
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Adam Roach
> *Sent:* Tuesday, July 29, 2014 11:19 AM
> *To:* Ivo Sedlacek; Robert Sparks; [email-masked]
> *Subject:* Re: [sipcore] Fwd: New Version Notification for 
>     out-of-dialog<< REFER request >>corresponding to a dialog
>     established by an INVITE request<< need to include
>
> the clarification had become worse than the source text; it was 
> actually more confusing.
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 31 Jul 2014 07:26:14 +0000

Hello,

According to the draft, the purpose of GRUU in Contact of INVITE request to "
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA."

If a UA rejects any out-of-dialog REFER requests corresponding to any dialogs related to an INVITE request, then setting up GRUU in Contact of INVITE does not provide any purpose.

This is true __regardless__ whether the UA supports and use the draft-sparks-sipcore-refer-explicitsub.
See attached mail giving an example of UA having two types of sessions, Type_A transferrable by REFER, and Type_B not transferrable by REFER.
Given that different standardization organization has defined so many enablers which can run on a single UA, I find it weird that one can guarantee that the above cannot occur.

Thus, I hesitate to mandate an unnecessary requirement influencing possible existing UA implementations and I prefer to be explicit on the exception for usage of GRUU in Contact of INVITE request:

   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. >>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE 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: Robert Sparks [mailto:[email-masked]]
Sent: 30. července 2014 18:54
To: Andrew Allen; Adam Roach; Ivo Sedlacek; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

On 7/30/14, 10:33 AM, Andrew Allen wrote:
I have a general concern with the direction this is now going.
I don't think you have the backwards-compatibility concern quite right, but I agree that the current wording isn't there yet.

Are we now saying here that it’s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)?
No, _this_ document is not defining new behavior. It's only clarifying what's already defined.

According to RFC 3515

a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs

I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC.
This, and what you have below, is a discussion we definitely need to have as part of the extension document.
It is not necessary to wait for that discussion to complete the clarifications document that talks about what the specs say _now_.

My discomfort with the current text is that we've made it complex to make it so that we don't have to update the document once the proposed extensions exist.
There are NO currently standardized cases where the exemption in the current text would be invoked, and I don't think people are trying to argue there are - I'm hearing that to get there, they expect to invoke the yet-to-be-defined extension.

In an attempt to be future-proof, that's introducing the potential for confusion about what the current standards define.
Let's remove that confusion.
Here's a proposed replacement, taking Adam's sentence simplification into account:

Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, July 29, 2014 11:19 AM
To: Ivo Sedlacek; Robert Sparks; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

So I'll counterpropose:

/a

Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt
From: Ivo Sedlacek <[email-masked]>
To: Robert Sparks <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 29 Jul 2014 14:52:20 +0000
List-Id: SIP Core Working Group <sipcore.ietf.org>

Hello,

Kind regards

Ivo Sedlacek

RjS

-------- Original Message --------

Subject:

Date:

From:

To:

Abstract:

The IETF Secretariat

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 31 Jul 2014 07:28:17 +0000

RFC3515 states:

2.4.2 Processing a REFER request
...
   If a REFER request is accepted (that is, a 2xx class response is
   returned), the recipient MUST create a subscription and send
   notifications of the status of the refer as described in Section
   2.4.4.

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: Andrew Allen [mailto:[email-masked]]
Sent: 30. července 2014 17:33
To: Adam Roach; Ivo Sedlacek; Robert Sparks; [email-masked]
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

According to RFC 3515

Andrew

So I'll counterpropose:

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 31 Jul 2014 07:29:00 +0000

(resending without the footer note, sorry about that). Kind regards Ivo Sedlacek

   If a REFER request is accepted (that is, a 2xx class response is
   returned), the recipient MUST create a subscription and send
   notifications of the status of the refer as described in Section
   2.4.4.From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 31. července 2014 9:26
To: Robert Sparks; Andrew Allen; Adam Roach; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hello,

Kind regards

Ivo Sedlacek

From: Robert Sparks [mailto:[email-masked]]
Sent: 30. července 2014 18:54
To: Andrew Allen; Adam Roach; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

According to RFC 3515

Andrew

So I'll counterpropose:

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Jul 2014 09:20:37 +0000

Hi Robert,

I agree that we should not define new behaviour in this draft.

However, I think your suggested text could be modified to say:

“A UA that will accept an out-of-dialog REFER request needs to include a GRUU in the Contact header field of all INVITE requests.  This ensures that out-of-dialog REFER requests corresponding to any resulting INVITE dialogs arrive at this UA. Future extensions [draft-sparks-sipcore-refer-explicitsub] might relax this requirement  by defining a REFER request that cannot create an implicit subscription.”

It does not introduce new functionality, as in-dialog REFERs can be sent without any extensions.

Regards,

Christer

Sent: 30 July 2014 19:54

According to RFC 3515

Andrew

So I'll counterpropose:

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jul 2014 09:01:06 -0500

> On Jul 31, 2014, at 4:20, Christer Holmberg <[email-masked]> wrote:
> 
> In-dialog REFERs can be sent without any extensions.
> 

If you're 6665 compliant, they can't. That's kind of the whole point of this document. 

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 31 Jul 2014 15:19:47 +0000

The point of this discussion is that there can be sessions for which out-of-dialog REFER request is rejected.

For such sessions, there is no point to include GRUU in Contact of INVITE request - any REFER sent to such GRUU will be rejected.

Kind regards

Ivo Sedlacek

From: Adam Roach [mailto:[email-masked]]
Sent: 31. července 2014 16:01
To: Christer Holmberg
Cc: Robert Sparks; Andrew Allen; Ivo Sedlacek; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

On Jul 31, 2014, at 4:20, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
In-dialog REFERs can be sent without any extensions.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Jul 2014 16:19:28 +0000

Correct. Dialog re-usage (which would occur due to an implicit subscription) was depricated.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Adam Roach <[email-masked]> wrote:

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 1 Aug 2014 06:44:40 +0000

Any comments on the proposal below?

Kind regards

Ivo Sedlacek

To: Robert Sparks; Andrew Allen; Adam Roach; [email-masked]<mailto:[email-masked]>

Hello,

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

So I'll counterpropose:

/a