Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 05 Jan 2015 09:36:57 -0600

Iterating on this (with comments inline later):

Add this as the 3rd paragraph of the introduction.

Note that there are implementations in some known specialized 
environments (such as 3gpp) that use out-of-signalling agreements to 
ensure that in-dialog REFER requests using the RFC4488 extension do not 
create a new subscription inside that dialog. In the 3gpp environment, 
the behavior is based on capabilities advertised using media feature 
tags. Such implementations revert to creating a subscription inside the 
dialog when interoperating with standard implementations outside those 
environments. The extensions in 
[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized 
alternative that prevents that additional dialog usage.

And make this fairly minor change to section 4:

   If a user agent has used standardized mechanisms to ensure 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 [I-D.ietf-sipcore-refer-explicit-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].

On 12/19/14 6:51 AM, Christer Holmberg wrote:
> Hi Robert,
>
> In general, the text looks good, and I also very much appreciate the fact that you are willing to work on a compromise. A couple of comments, though.
>
> Q1: I don't think the statement regarding failed interoperability is correct (Ivo has previously explained how it would work), so I suggest to remove that. But, instead I suggest to extend the last sentence to:
>
> 	"The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative, which is also expected to be used future implementations in the specialized environments mentioned above."
I took a slightly different approach that I hope resolves the tension. I 
don't think we should add what we think 3gpp will go do with this into 
the document - we only need to say what can be done.
>
> Q2: Your suggested section 4 text says:
>
> 	"If a user agent has used standardized mechanisms to ensure 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 [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER
>    	request MAY be sent within an existing dialog."
>
> To a reader that hasn't been following this discussion it may seem like you're "overwriting" the earlier statement regarding specialized environments, so personally I think we could keep the existing text (starting with "If a user agent can be certain...").
I think the proposed text is exactly what we're trying to say - it's 
defining the proposed standard for the internet.
In the system described by the RFC series, it is not ok to send that 
REFER in the existing dialog.
This document (with the proposed text here) is acknowledging that the 
behavior occurs in specialized environments, but it does not make it 
standard behavior on the Internet. The proposed text in no way takes 
overwrites the earlier statement that the behavior in those specialized 
environments exists.
>
> Regards,
>
> Christer
>
>
>
>
> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: 19. joulukuuta 2014 0:46
> To: [email-masked]
> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt
>
> So, does this text work to accomplish the goal:
>
>
> We put this as the 3rd paragraph of the introduction.
>
> Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations will fail to interoperate with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative.
>
> And make this fairly minor change to section 4:
>
>    If a user agent has used standardized mechanisms to ensure 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 [I-D.ietf-sipcore-refer-explicit-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].
>
> RjS
>
> On 12/18/14 10:57 AM, Christer Holmberg wrote:
>> Hi,
>>
>>>> Can you live with this as a compromise?
>>>>
>>>> Basically document and accept that there are existing applications
>>>> which use RFC4488 and feature tags to indicate that the UAS will accept the UAC request not to create a subscription.
>>>> But deprecate this behavior for new applications going forward and
>>>> require for future applications the use of [I-D.ietf-sipcore-refer-explicit-subscription] in order to reuse then existing dialog.
>>> I'm not in love with it, but I can live with it. I'm still
>>> apprehensive about the precedent of condoning out-of-spec behavior
>>> after the fact, and would prefer something that drives 3GPP to incorporate more compliant behavior in future revisions. But if everyone else is happy with this general principle, I'll stay out of the way.
>> I appreciate that you can live with the compromise.
>>
>> And, again, as we now will have an IETF mechanism, I am sure 3GPP will use it in any future use-cases. At least I would push for it, and I see no reason why others wouldn't.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Robert Sparks <[email-masked]>
Date: Mon, 05 Jan 2015 09:37:46 -0600

Thanks Ivo -

I think I've aligned the proposed text to this (see the other thread). 
Does it work for you?

RjS

On 12/22/14 1:54 AM, Ivo Sedlacek wrote:
>> I went looking for that explanation to refresh my memory, but couldn't find
>> it quickly. Can you provide a pointer?
> In short:
> - UAC of the initial INVITE request indicates support of a feature using a media feature tag and support of norefersub in the initial INVITE request.
> - the REFER with norefersub is sent (by the UA which acted as the UAS of the initial INVITE request) within the dialog *ONLY* if the UAC of initial INVITE request indicated the media feature tag and support of norefersub in the initial INVITE request.
> - description of the feature associated with the media feature tag guarantees that recipient of the REFER with norefersub will accept the REFER without creating an implicit subscription.
>
> The original mail with the short description is attached.
> 	
> Kind regards
>
> Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 6 Jan 2015 10:18:33 +0000

Hello Robert,

IMO, the statement "Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments. " is incorrect.

In 3GPP use case:
1) the particular media feature tag indicates that the UA ensures NOT creating the subscription inside the dialog for received REFERs with norefersub
2) UA-A sending INVITE request includes the particular media feature tag in INVITE request and thus indicates support of the feature in the bullet 1.
3) when UA-B receives an INVITE request:
	- if the INVITE request contains the particular media feature tag - i.e. UA-A sending the INVITE request supports feature in bullet 1, the UA-B can safely send in-dialog REFER with norefersub. UA-A will ensure that the subscription inside the dialog is not created due to bullet 1.
	- if the INVITE request does not contain the particular media feature tag, the UA-B does not send in-dialog REFER to UA-A.

Why would this procedure "revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments"?

Thus, I would prefer to keep the existing text in section 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 

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 5. ledna 2015 16:37
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that prevents that additional dialog usage.

> 	"The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative, which is also expected to be used future implementations in the specialized environments menti…
I took a slightly different approach that I hope resolves the tension. I don't think we should add what we think 3gpp will go do with this into the document - we only need to say what can be done.
> To a reader that hasn't been following this discussion it may seem like you're "overwriting" the earlier statement regarding specialized environments, so personally I think we could keep the existi…
I think the proposed text is exactly what we're trying to say - it's defining the proposed standard for the internet.
In the system described by the RFC series, it is not ok to send that REFER in the existing dialog.
This document (with the proposed text here) is acknowledging that the behavior occurs in specialized environments, but it does not make it standard behavior on the Internet. The proposed text in no way takes overwrites the earlier statement that the behavior in those specialized environments exists.
> Subject: Re: [sipcore] I-D Action: 
> draft-ietf-sipcore-refer-clarifications-00.txt
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 06 Jan 2015 07:44:03 -0600

> 	- if the INVITE request does not contain the particular media feature tag, the UA-B does not send in-dialog REFER to UA-A.
So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that 
doesn't provide that media feature tag, correct?

So, in the very last case above, do you send the REFER out-of-dialog, or 
do you refuse to send a REFER at all?

If you send the REFER out-of-dialog, what do you do if  UA-A doesn't 
accept out-of-dialog REFER requests?

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 6 Jan 2015 15:11:03 +0000

Hello,

> > 1) the particular media feature tag indicates that the UA ensures NOT 
> > creating the subscription inside the dialog for received REFERs with 
> > norefersub
> So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that doesn't provide that media feature tag, correct?

Correct.

> So, in the very last case above, do you send the REFER out-of-dialog, or do you refuse to send a REFER at all?

If the INVITE request does not contain the particular media feature tag, the UA-B does not send REFER to UA-A - neither in-dialog, nor out-of-dialog.

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Fri, 09 Jan 2015 09:48:58 -0600

>> So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that doesn't provide that media feature tag, correct?
And for completeness, you will always reject any REFER sent from such a UA?

---

From: Robert Sparks <[email-masked]>
Date: Fri, 09 Jan 2015 11:13:41 -0600

Ok. One more try, reflecting my understanding of what Ivo has provided 
in the changes to the introduction.
Please make sure what it says is true (particularly the "or accept" part).

Add this as the 3rd paragraph of the introduction:

Note that there are implementations in some known specialized 
environments (such as 3gpp) that use out-of-signalling agreements to 
ensure that in-dialog REFER requests using the RFC4488 extension do not 
create a new subscription inside that dialog. In the 3gpp environment, 
the behavior is based on capabilities advertised using media feature 
tags. Such implementations will never send or accept any REFER from a 
peer that hasn't provided those media feature tags. The extensions in 
[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized 
alternative.

And leave the text in section 4 as is.

On 1/5/15 9:36 AM, Robert Sparks wrote:
> ensure that in-dialog REFER requests using the RFC4488 extension do 
> not create a new subscription inside that dialog. In the 3gpp 
> environment, the behavior is based on capabilities advertised using 
> media feature tags. Such implementations revert to creating a 
> subscription inside the dialog when interoperating with standard 
> implementations outside those environments. The extensions in 
>> In general, the text looks good, and I also very much appreciate the 
>> fact that you are willing to work on a compromise. A couple of 
>> comments, though.
>>
>> Q1: I don't think the statement regarding failed interoperability is 
>> correct (Ivo has previously explained how it would work), so I 
>> suggest to remove that. But, instead I suggest to extend the last 
>> sentence to:
>>
>>     "The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] 
>> provide a standardized alternative, which is also expected to be used 
>> future implementations in the specialized environments mentioned above."
> I took a slightly different approach that I hope resolves the tension. 
> I don't think we should add what we think 3gpp will go do with this 
> into the document - we only need to say what can be done.
>>
>> To a reader that hasn't been following this discussion it may seem 
>> like you're "overwriting" the earlier statement regarding specialized 
>> environments, so personally I think we could keep the existing text 
>> (starting with "If a user agent can be certain...").
> overwrites the earlier statement that the behavior in those 
> specialized environments exists.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>> ensure that in-dialog REFER requests using the RFC4488 extension do 
>> not create a new subscription inside that dialog. In the 3gpp 
>> environment, the behavior is based on capabilities advertised using 
>> media feature tags. Such implementations will fail to interoperate 
>> with standard implementations outside those environments. The 
>> extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide 
>> a standardized alternative.
>>
>>>>> which use RFC4488 and feature tags to indicate that the UAS will 
>>>>> accept the UAC request not to create a subscription.
>>>>> require for future applications the use of 
>>>>> [I-D.ietf-sipcore-refer-explicit-subscription] in order to reuse 
>>>>> then existing dialog.
>>>> after the fact, and would prefer something that drives 3GPP to 
>>>> incorporate more compliant behavior in future revisions. But if 
>>>> everyone else is happy with this general principle, I'll stay out 
>>>> of the way.
>>> And, again, as we now will have an IETF mechanism, I am sure 3GPP 
>>> will use it in any future use-cases. At least I would push for it, 
>>> and I see no reason why others wouldn't.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 13 Jan 2015 06:59:00 +0000

Hello,

> >>> 1) the particular media feature tag indicates that the UA ensures

> >>> NOT creating the subscription inside the dialog for received REFERs

> >>> with norefersub

> >>> 2) UA-A sending INVITE request includes the particular media feature tag

> in INVITE request and thus indicates support of the feature in the bullet 1.

> >>>    - if the INVITE request contains the particular media feature tag - i.e.

> UA-A sending the INVITE request supports feature in bullet 1, the UA-B can

> safely send in-dialog REFER with norefersub. UA-A will ensure that the

> subscription inside the dialog is not created due to bullet 1.

> >>>    - if the INVITE request does not contain the particular media feature

> tag, the UA-B does not send in-dialog REFER to UA-A.

> And for completeness, you will always reject any REFER sent from such a UA?

The flow in 3GPP TS 24.237 (where the procedure above is defined and used) is as follows (only tags important for this discussion are listed):

 Alice                                                                  Bob

   |-------- 1. INVITE (media feature tag X)---------------------------->|

    |<------- 2. 200 for INVITE ------------------------------------------|

    |-------- 3. ACK----------------------------------------------------->|

    |                                          4. *ONLY* if media feature tag X is present in the INVITE,

    |                                                          step 5 is performed

    |<------- 5. in-dialog REFER (norefersub, Refer-Sub: false)-----------|

6. *ONLY* if norefersub and Refer-Sub: false                              |

are included in the in-dialog REFER, steps 7 and 8 are performed          |

    |-------- 7. 200 for in-dialog REFER ---------------------------------|

8. don't create implicit subscription                                     |

    |                                                                     |

3GPP TS 24.237:

- does not give any statements how Alice is to handle a received in-dialog REFER without norefersub and without Refer-Sub: false. If norefersub is missing or if Refer-Sub: false is missing in the received in-dialog REFER, then RFC3515 and RFC6665 rules apply.

- does not give any statements how Bob is to handle a received in-dialog REFER. RFC3515 and RFC6665 rules apply for the received in-dialog REFER.

Does this clarify the question?

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 13 Jan 2015 08:09:45 +0000

Hello,

> media feature tags. Such implementations will never send or accept any 
> REFER from a peer that hasn't provided those media feature tags. The 
> extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative.

IMO, it would be more appropriate to state:
---------------
Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. >>In the 3gpp environment, <<such implementations >>by definition<<< will never send >>an in-dialog<< REFER request >>to<< a peer that hasn't provided those media feature tags >>and never accept in-dialog REFER request without norefersub and without Refer-Sub: false<<. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative.
---------------
 
> And leave the text in section 4 as is.

OK.

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jan 2015 08:59:37 -0600

On 1/13/15 12:59 AM, Ivo Sedlacek wrote:
> The flow in 3GPP TS 24.237 (where the procedure above is defined and 
> used) is as follows (only tags important for this discussion are listed):
>
>  Alice                                                               Bob
>
>     |<------- 2. 200 for INVITE 
> ------------------------------------------|
>
>     |-------- 3. 
> ACK----------------------------------------------------->|
>
>     |                                          4. *ONLY* if media 
> - does not give any statements how Alice is to handle a received 
> in-dialog REFER without norefersub and without Refer-Sub: false. If 
> norefersub is missing or if Refer-Sub: false is missing in the 
> received in-dialog REFER, then RFC3515 and RFC6665 rules apply.
>
Then my currently proposed text is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the 
dialog when interoperating with standard implementations outside those 
environments."

> - does not give any statements how Bob is to handle a received 
> in-dialog REFER. RFC3515 and RFC6665 rules apply for the received 
> in-dialog REFER.
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jan 2015 09:01:41 -0600

On 1/13/15 2:09 AM, Ivo Sedlacek wrote:
> Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. >>In the 3gpp environment, <<such implementations >>by definition<<< will never send >>an in-dialog<< REFER request >>to<< a peer that hasn't provided those media feature tags >>and never accept in-dialog REFER request without norefersub and without Refer-Sub: false<<.
That "never accept" doesn't say the same thing as your other message 
where you said they followed 3515 or 6665.
>   The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative.
> ---------------
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jan 2015 09:13:07 -0600

On 1/13/15 2:09 AM, Ivo Sedlacek wrote:
> Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags.

> >>In the 3gpp environment,
The problem the original text is trying to point out is what happens 
when one of the implementations is _not_ from the 3gpp environment.
> <<such implementations >>by definition<<< will never send >>an in-dialog<< REFER request >>to<< a peer that hasn't provided those media feature tags >>and never accept in-dialog REFER request without norefersub and without Refer-Sub: false<<. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative.
> ---------------
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 13 Jan 2015 15:17:42 +0000

Hello Robert,

3GPP TS 24.237:

- does not give any statements how Alice is to handle a received in-dialog REFER without norefersub and without Refer-Sub: false. If norefersub is missing or if Refer-Sub: false is missing in the received in-dialog REFER, then RFC3515 and RFC6665 rules apply.
Then my currently proposed text is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments."

You asked how the 3GPP solution acts when a REFER request *NOT* described by 3GPP solution is received by 3GPP entity.

My answer was that in such case the UA acts as in RFC3515 and RFC6665.

You claim that such implementation reverts to creating a subscription inside the dialog when interoperating with standard implementations outside those environments.

If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those described in the 3GPP solution, reverts to creating a subscription inside the dialog when interoperating with standard implementations.

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jan 2015 09:27:58 -0600

On 1/13/15 9:17 AM, Ivo Sedlacek wrote:
>     in-dialog REFER without norefersub and without Refer-Sub: false.
>     If norefersub is missing or if Refer-Sub: false is missing in the
> You asked how the 3GPP solution acts when a REFER request *NOT* 
> described by 3GPP solution is received by 3GPP entity.
>
> You claim that such implementation reverts to creating a subscription 
> inside the dialog when interoperating with standard implementations 
> outside those environments.
>
> If that's correct, then *EACH* UA implementation of RFC3515 and 
> RFC6665,*NOT* limited to those described in the 3GPP solution, reverts 
> to creating a subscription inside the dialog when interoperating with 
> standard implementations.
>
you should be saying _or_ to account for the fielded implementations of 
3515 that don't know 6665.

And that's exactly my point - without standardized extension, those 
implementions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation 
can return a 421/Require to REFER requests that don't use the extension 
and would create dialog reuse.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Jan 2015 09:16:37 +0000

Hi,

I am a little lost...

If 3GPP-Bob receives a INVITE request WITHOUT the media feature tag, 3GPP-Bob will not send in-dialog REFERs.

If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

Regards,

Christer

From: Robert Sparks [mailto:[email-masked]]
Sent: 13. tammikuuta 2015 17:28
To: Ivo Sedlacek; Christer Holmberg; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

3GPP TS 24.237:

If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those described in the 3GPP solution, reverts to creating a subscription inside the dialog when interoperating with standard implementations.
you should be saying _or_ to account for the fielded implementations of 3515 that don't know 6665.

And that's exactly my point - without standardized extension, those implementions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation can return a 421/Require to REFER requests that don't use the extension and would create dialog reuse.

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Jan 2015 08:01:17 -0600

On 1/14/15 3:16 AM, Christer Holmberg wrote:
> I am a little lost…
Thanks for reconfirming that.
>
> If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog 
> REFER from an entity that does not support any mechanism (standardized 
> or 3GPP-specific), there obviously is risk of a dialog reuse. But, 
> that is according to the backward compatibility rules in RFC6665, and 
> ANY entity has to be able to deal with that somehow.
>
Which, when the peer is an unextended UA, is to fall back and use 3515, 
hence fall back to dialog reuse.

Let me take yet another stab at the paragraph for the introduction, 
given this set of exchanges. Please read it in the context of the 
introduction, not just in isolation:

Note that there are implementations in some known specialized 
environments (such as 3gpp) that use out-of-signalling agreements to 
ensure that in-dialog REFER requests using the RFC4488 extension do not 
create a new subscription inside that dialog. In the 3gpp environment, 
the behavior is based on capabilities advertised using media feature 
tags. Such implementations revert to RFC 3515 (as described in section 
4.5.2 of RFC6665), creating a subscription inside the dialog when 
interoperating with standard implementations outside those environments. 
The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide 
a standardized alternative that allows avoiding any additional dialog usage.

> Regards,
>
> Christer
>
> *From:*Robert Sparks [mailto:[email-masked]]
> *Sent:* 13. tammikuuta 2015 17:28
> *To:* Ivo Sedlacek; Christer Holmberg; [email-masked]
> *Subject:* Re: [sipcore] I-D Action: 
>         - does not give any statements how Alice is to handle a
>         received in-dialog REFER without norefersub and without
>         Refer-Sub: false. If norefersub is missing or if Refer-Sub:
>         false is missing in the received in-dialog REFER, then RFC3515
>         and RFC6665 rules apply.
>
>     dialog when interoperating with standard implementations outside
>     those environments."
>
>
>
>     You claim that such implementation reverts to creating a
>     implementations outside those environments.
>
>     RFC6665,*NOT* limited to those described in the 3GPP solution,
>     reverts to creating a subscription inside the dialog when
>     interoperating with standard implementations.
>
> can return a 421/Require to REFER requests that don't use the 
> extension and would create dialog reuse.
>
> Kind regards
>
> Ivo Sedlacek
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Jan 2015 14:47:57 +0000

Hi Robert,

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there
>obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.
>
>Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.

Your suggested "Such implementations" wording make it sound like only 3GPP entities will revert :)

What about?

"There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to
ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp
environment, the behavior is based on capabilities advertised using media feature tags.
SIP implementations will revert to RFC 3515  (as described in section 4.5.2 of RFC6665), creating a subscription
inside the dialog, when interoperating with implementations that do not support a mechanism for avoiding
additional dialog usage. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized
mechanism that allows avoiding any additional dialog usage."

Or, perhaps we should FIRST say what happens when the remote peer is unextended.

"SIP implementations will revert to RFC 3515  (as described in section 4.5.2 of RFC6665), creating a subscription
inside the dialog, when interoperating with implementations that do not support a mechanism for avoiding
additional dialog usage.

There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to
ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp
environment, the behavior is based on capabilities advertised using media feature tags.

The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding
any additional dialog usage."

Regards,

Christer

Let me take yet another stab at the paragraph for the introduction, given this set of exchanges. Please read it in the context of the introduction, not just in isolation:

Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to RFC 3515 (as described in section 4.5.2 of RFC6665), creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that allows avoiding any additional dialog usage.

Regards,

Christer

From: Robert Sparks [mailto:[email-masked]]
Sent: 13. tammikuuta 2015 17:28
To: Ivo Sedlacek; Christer Holmberg; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

3GPP TS 24.237:

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Jan 2015 09:03:37 -0600

On 1/14/15 8:47 AM, Christer Holmberg wrote:
> or 3GPP-specific), there
> >obviously is risk of a dialog reuse. But, that is according to the 
> backward compatibility rules in RFC6665, and ANY entity has to be able 
> to deal with that somehow.
>
> >
>
> Your suggested “Such implementations” wording make it sound like only 
> 3GPP entities will revert :)
>
It is exactly the 3gpp entities that this paragraph is about.

I don't agree that pulling in the general case helps with the text.

The point of the addition was to acknowledge that there was some 
non-standard behavior that elements might encounter and point to the 
edges of that behavior. Can we hold it to that scope?

> What about?
>
> “There are implementations in some known specialized environments 
> (such as 3gpp) that use out-of-signalling agreements to
>
> media feature tags.
> SIP implementations will revert to RFC 3515  (as described in section 
> 4.5.2 of RFC6665), creating a subscription
>
> additional dialog usage. The extensions in 
> mechanism that allows avoiding any additional dialog usage.”
>
> “SIP implementations will revert to RFC 3515  (as described in section 
> 4.5.2 of RFC6665), creating a subscription
>
> There are implementations in some known specialized environments (such 
> as 3gpp) that use out-of-signalling agreements to
>
> media feature tags.
> The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] 
> provide a standardized mechanism that allows avoiding
>
> any additional dialog usage.”
>
> Regards,
>
> Christer
>
>
>
>
>
> media feature tags. Such implementations revert to RFC 3515 (as 
> described in section 4.5.2 of RFC6665), creating a subscription inside 
> the dialog when interoperating with standard implementations outside 
> those environments. The extensions in 
> alternative that allows avoiding any additional dialog usage.
>
>
>
> Regards,
>
> Christer
>
> <mailto:[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 14 Jan 2015 15:33:18 +0000

How is behaviour of the 3GPP entity different from behaviour of an IETF entity supporting RFC6665 and RFC3515 when interworking with an unextended UA sending in-dialog REFER?

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Jan 2015 09:44:36 -0600

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:
>
> >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does 
> not support any mechanism (standardized or 3GPP-specific), there
>
> >obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in 
> RFC6665, and ANY entity has to be able to deal with that somehow.
>
> >
>
> How is behaviour of the 3GPP entity different from behaviour of an 
> IETF entity supporting RFC6665 and RFC3515 when interworking with an 
> unextended UA sending in-dialog REFER?
>
Please go read my proposed text again. Whether it's the same or 
different, the text is accurate, and calls out the edge case that 
matters for this document. Whether you can end up with the same or 
different fallback paths in other circumstances is irrelevant.

If you want to increase the accuracy, we can add text about how the 
unextended UA won't even be aware that something was _trying_ or was 
capable of invoking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew 
pointed to back in December. The focus of this paragraph needs to remain 
on the private application.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Jan 2015 19:08:50 +0000

Hi,

I THINK I've found the reason why we seem to talk past each other :)

If I understand Robert correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with an unextended UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that correct, Robert?

If so, perhaps we instead of talking about the 3GPP implementations could talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use when interworking with unextended UAs.

That way we put the focus on the mechanism, rather than on the UAs, and it also matches the subsequent sentence about standardized mechanism better.

Something like:

"There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to
ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp
environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent
additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in
[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage."

Regards,

Christer

From: Robert Sparks [mailto:[email-masked]]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

How is behaviour of the 3GPP entity different from behaviour of an IETF entity supporting RFC6665 and RFC3515 when interworking with an unextended UA sending in-dialog REFER?
Please go read my proposed text again. Whether it's the same or different, the text is accurate, and calls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstances is irrelevant.

If you want to increase the accuracy, we can add text about how the unextended UA won't even be aware that something was _trying_ or was capable of invoking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew pointed to back in December. The focus of this paragraph needs to remain on the private application.

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Jan 2015 14:11:31 -0600

On 1/14/15 1:08 PM, Christer Holmberg wrote:
>
> Hi,
>
> I THINK I’ve found the reason why we seem to talk past each other :)
>
> If I understand Robert correctly, he simply wants to clarify that the 
> *3GPP mechanism* does not prevent dialog re-use when interworking with 
> an unextended UAs from sending an in-dialog REFER. Nothing more, 
> nothing less. Is that correct, Robert?
>
> If so, perhaps we instead of talking about the 3GPP implementations 
> could talk about the *3GPP MECHANISM*, and state that it does not 
> prevent dialog re-use when interworking with unextended UAs.
>
> That way we put the focus on the mechanism, rather than on the UAs, 
> and it also matches the subsequent sentence about standardized 
> mechanism better.
>
> Something like:
>
> media feature tags. That mechanism does not, however, prevent
>
> additional dialog usages when interoperating with implementations that 
> do not support the mechanism. The extensions in
>
I would be fine with that text.
> *Sent:* 14 January 2015 17:45
>     >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that
>     does not support any mechanism (standardized or 3GPP-specific), there
>
>     >obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules
>     in RFC6665, and ANY entity has to be able to deal with that somehow.
>
>     >
>
>     Your suggested “Such implementations” wording make it sound like
>     only 3GPP entities will revert :)
>
>     IETF entity supporting RFC6665 and RFC3515 when interworking with
>     an unextended UA sending in-dialog REFER?
>
> The goal of this additional text was to reach the compromise that 
> Andrew pointed to back in December. The focus of this paragraph needs 
> to remain on the private application.
>
>     Kind regards
>
>     Ivo Sedlacek
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 15 Jan 2015 08:05:06 +0000

Hello Robert,

In order to avoid any misunderstandings among future readers of the draft on what is the route cause of the problem, I'd like to add the following statement to the beginning: "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665."

Also, I think the last sentence needs to be aligned with second last sentence.

I.e.

"RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665. There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to
ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp
environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent
additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in
[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage when interoperating with implementations that do not support the mechanism."

If this is acceptable, I would be OK with this text.

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: 14. ledna 2015 21:12
To: Christer Holmberg; Ivo Sedlacek; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Something like:

Regards,

Christer

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Thu, 15 Jan 2015 09:03:03 -0600

On 1/15/15 2:05 AM, Ivo Sedlacek wrote:
>
> Hello Robert,
>
> In order to avoid any misunderstandings among future readers of the 
> draft on what is the route cause of the problem, I'd like to add the 
> following statement to the beginning: "RFC3515 and RFC6665 do not 
> prevent additional dialog usages when interoperating with 
> implementations that do not support RFC6665."
>
I don't agree. I think this addition would be unnecessary and not helpful.
> “RFC3515 and RFC6665 do not prevent additional dialog usages when 
> interoperating with implementations that do not support RFC6665. There 
> are implementations in some known specialized environments (such as 
> 3gpp) that use out-of-signalling agreements to
>
> mechanism that allows avoiding any additional dialog usage when 
> interoperating with implementations that do not support the mechanism.”
>
Again, I don't agree. The sentence is correct without the clause you add 
- it covers avoiding additional dialog usage in general, not just in the 
case the added clause calls out.
> 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>
>
> *Sent:* 14. ledna 2015 21:12
> *To:* Christer Holmberg; Ivo Sedlacek; [email-masked]
>     If I understand Robert correctly, he simply wants to clarify that
>     the *3GPP mechanism* does not prevent dialog re-use when
>     interworking with an unextended UAs from sending an in-dialog
>     REFER. Nothing more, nothing less. Is that correct, Robert?
>
>     If so, perhaps we instead of talking about the 3GPP
>     implementations could talk about the *3GPP MECHANISM*, and state
>     that it does not prevent dialog re-use when interworking with
>     unextended UAs.
>
>     That way we put the focus on the mechanism, rather than on the
>     UAs, and it also matches the subsequent sentence about
>     standardized mechanism better.
>
>     Something like:
>
>     ensure that in-dialog REFER requests using the RFC4488 extension
>     do not create a new subscription inside that dialog. In the 3gpp
>
>     environment, the behavior is based on capabilities advertised
>     using media feature tags. That mechanism does not, however, prevent
>
>     additional dialog usages when interoperating with implementations
>     that do not support the mechanism. The extensions in
>
>     [I-D.ietf-sipcore-refer-explicit-subscription] provide a
>     standardized mechanism that allows avoiding any additional dialog
>     usage.”
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 16 Jan 2015 08:16:53 +0000

Hello Robert,

I re-checked the draft and found that the text (2nd paragraph in section 2) immediately preceding the new addition more or less covers what I wanted to say with "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665."

Thus, I am OK with text proposed by Christer.

Kind regards

Ivo Sedlacek

Sent: 15. ledna 2015 16:03

I.e.

Again, I don't agree. The sentence is correct without the clause you add - it covers avoiding additional dialog usage in general, not just in the case the added clause calls out.

Kind regards

Ivo Sedlacek

To: Christer Holmberg; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>

Something like:

Regards,

Christer

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Jan 2015 08:57:52 -0600

On 1/16/15 2:16 AM, Ivo Sedlacek wrote:
>
> Hello Robert,
>
> I re-checked the draft and found that the text (2nd paragraph in 
> section 2) immediately preceding the new addition more or less covers 
> what I wanted to say with "RFC3515 and RFC6665 do not prevent 
> do not support RFC6665."
Thanks Ivo.

I'll send in a new version

RjS
> *Sent:* 15. ledna 2015 16:03
>     In order to avoid any misunderstandings among future readers of
>     the draft on what is the route cause of the problem, I'd like to
>     add the following statement to the beginning: "RFC3515 and RFC6665
>     do not prevent additional dialog usages when interoperating with
> Again, I don't agree. The sentence is correct without the clause you 
> add - it covers avoiding additional dialog usage in general, not just 
> in the case the added clause calls out.
>