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

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 1 Dec 2014 09:48:30 +0000

Hi,

I support the proposal from Ivo, it caters for existing deployments.

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Monday, December 01, 2014 8:50 AM
To: Ivo Sedlacek; Andrew Allen; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

I think the text suggested by Ivo looks good. It makes it clear that [I-D.ietf-sipcore-refer-explicit-subscription] IS the "pure" protocol mechanism for preventing an implicit subscription, while there exists "special environments" where it is dealt with using other means.

The only reason these "special environment" use-cases exist to begin with is because previously there was no "pure" protocol mechanism for preventing implicit subscriptions. And, as they have existed for a while already, and have been implemented, they will not suddenly go away just because we now have [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go away just because we now have drafts clarifying some RFCs. 

BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-refer-explicit-subscription] for preventing implicit subscriptions, I assume there will be no NEW "special environment" use-cases in future - people WILL use [I-D.ietf-sipcore-refer-explicit-subscription] :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 28. marraskuuta 2014 17:29
To: Ivo Sedlacek; Andrew Allen; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hello,

I think Andrew's proposed statement can be replaced by the statement already existing in the draft, i.e.
=============
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
   [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request
   MAY be sent within an existing dialog.
=============
and extended as follows:
=============
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
   [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 together with configuration / application logic in specific environment  ensuring that implicit subscription is not created<<<), the REFER request
   MAY be sent within an existing dialog.
=============

Kind regards

Ivo Sedlacek

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 28. listopadu 2014 8:38
To: Andrew Allen; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hello,

I disagree with proposed statement: 

"Only 
   when using the explicit subscription mechanism to require that
   a subscription not be created MAY the REFER request be sent 
   within an existing dialog."

There are existing means how the UA can be sure that implicit subscription will not be created - they rely on media feature tag and RFC4488, but work neverthless.

Therefore, I see the proposed statement as unnecessary restrictive. RFC6665 statement is sufficient.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 28. listopadu 2014 2:04
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Robert

Thanks for getting the WG version of the draft out.

The main issue for me with the draft is the criteria for how the UA knows that it will not end up with an explicit subscription. Currently the draft is vague about that.

Some deployments don't currently have the potential to create an implicit subscription because of something defined outside of the SIP protocol ensures that they only perform a subset of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that the UAC always includes refersub=false and by defining that the UAS always accepts that request to not create a subscription with the only way for a UAC to determine that the UAS will behave that way is because it (maybe) received a media-feature tag or feature capability indicator that it knows by means outside the SIP protocol (from some other SDOs specification or it's a proprietary implementation where a single vendor defines both ends) that this will be the behavior.

I think we should clearly decide whether this fulfils the criteria for a UAC to determine definitively that no implicit subscription will be created and hence allows the UAC to send the Refer on an existing dialog or not. 

My own preference is not to have this qualify as a way for a UAC to be certain as this makes SIP protocol behavior dependent on some higher layer application semantic creating a tight coupling between the application and the SIP protocol stack making it difficult to reuse off the shelf SIP stacks for you application. It should be a protocol issue (defined in RFCs) not an application issue as to whether a request is sent on the same or a different dialog.

I am also concerned that this kind of thing makes it more likely that the UAS in these cases ends up being only a partial implementation of the protocol (e.g. It doesn't even implement receiving a Refer out of dialog and cannot send a Notify even if a UAC did not include Refersub = false). I think the discussion we had in Dispatch in Hawaii shows that future interoperability problems are caused when only partial implementations of the protocol are done and assumptions about the behavior in perpetuity of the UAC are made.

My preference is that refer-clarifications should only allow refer-explicit-subscription mechanism as a means for UAC to determine that its ok to send the Refer on an existing dialog and that we make refer-clarifications dependent on refer-explicit-subscription. If you want to send on an existing dialog then you use the refer-explicit-subscription mechanism and Require nosub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the target  then you send outside the existing dialog. That is clear and deterministic.

So my proposal is to change the following text in section 4 from :

   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
   [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].

To

   A user agent can be certain that no implicit subscription will be
   created as a result of sending a REFER request by using the
   extension in [I-D.ietf-sipcore-refer-explicit-subscription] to 
   require the UAS not to create an implicit subscription. Only 
   when using the explicit subscription mechanism to require that
   a subscription not be created MAY the REFER request 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].

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, November 21, 2014 6:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

        Title           : Clarifications for the use of REFER with RFC6665
        Authors         : Robert Sparks
                          Adam Roach
	Filename        : draft-ietf-sipcore-refer-clarifications-00.txt
	Pages           : 6
	Date            : 2014-11-21

Abstract:
   The SIP REFER method relies on 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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2014 13:16:53 -0500

> I think Andrew's proposed statement can be replaced by the statement already existing in the draft, i.e.

What criteria do you use to be *certain*?

Some agreement of compliance to some specification seems to be required.

I gather that what you have in mind is that both ends have been verified 
to conform to particular versions of the IMS specification. Do you ever 
really know that for certain in the presence of gateways to foreign devices?

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 01 Dec 2014 14:50:56 -0600

On 12/1/14 12:16 PM, Paul Kyzivat wrote:
>>     [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 
>> together with configuration / application logic in specific 
>> environment  ensuring that implicit subscription is not created<<<), 
>> the REFER request
> I gather that what you have in mind is that both ends have been 
> verified to conform to particular versions of the IMS specification. 
> Do you ever really know that for certain in the presence of gateways 
> to foreign devices?

To amplify this point:

What you propose is exactly like saying "You don't have to implement 
congestion control in your TCP stack if you're only going to use TCP in 
an environment where the applications have agreed to never cause 
congestion".

And it's not ok for an Internet standard to say things like that, 
because it won't work with things on the Internet.

To _get_ it to work on the Internet, you'd have to signal compliance 
somehow.

>> Subject: Re: [sipcore] I-D Action: 
>> draft-ietf-sipcore-refer-clarifications-00.txt
>>
>> Hello,
>>
>> There are existing means how the UA can be sure that implicit 
>> subscription will not be created - they rely on media feature tag and 
>> RFC4488, but work neverthless.
>>
>> Subject: Re: [sipcore] I-D Action: 
>> draft-ietf-sipcore-refer-clarifications-00.txt
>>
>> Robert
>>
>> The main issue for me with the draft is the criteria for how the UA 
>> knows that it will not end up with an explicit subscription. 
>> Currently the draft is vague about that.
>>
>> Some deployments don't currently have the potential to create an 
>> implicit subscription because of something defined outside of the SIP 
>> protocol ensures that they only perform a subset of the defined 
>> behavior in RFCs 3515, 6665 and 4488 i.e. by defining that the UAC 
>> always includes refersub=false and by defining that the UAS always 
>> accepts that request to not create a subscription with the only way 
>> for a UAC to determine that the UAS will behave that way is because 
>> it (maybe) received a media-feature tag or feature capability 
>> indicator that it knows by means outside the SIP protocol (from some 
>> other SDOs specification or it's a proprietary implementation where a 
>> single vendor defines both ends) that this will be the behavior.
>>
>> I think we should clearly decide whether this fulfils the criteria 
>> for a UAC to determine definitively that no implicit subscription 
>> will be created and hence allows the UAC to send the Refer on an 
>> existing dialog or not.
>>
>> My own preference is not to have this qualify as a way for a UAC to 
>> be certain as this makes SIP protocol behavior dependent on some 
>> higher layer application semantic creating a tight coupling between 
>> the application and the SIP protocol stack making it difficult to 
>> reuse off the shelf SIP stacks for you application. It should be a 
>> protocol issue (defined in RFCs) not an application issue as to 
>> whether a request is sent on the same or a different dialog.
>>
>> I am also concerned that this kind of thing makes it more likely that 
>> the UAS in these cases ends up being only a partial implementation of 
>> the protocol (e.g. It doesn't even implement receiving a Refer out of 
>> dialog and cannot send a Notify even if a UAC did not include 
>> Refersub = false). I think the discussion we had in Dispatch in 
>> Hawaii shows that future interoperability problems are caused when 
>> only partial implementations of the protocol are done and assumptions 
>> about the behavior in perpetuity of the UAC are made.
>>
>> My preference is that refer-clarifications should only allow 
>> refer-explicit-subscription mechanism as a means for UAC to determine 
>> that its ok to send the Refer on an existing dialog and that we make 
>> refer-clarifications dependent on refer-explicit-subscription. If you 
>> want to send on an existing dialog then you use the 
>> refer-explicit-subscription mechanism and Require nosub otherwise you 
>> follow the RFC 6665 behavior and if you have a GRUU as the target  
>> then you send outside the existing dialog. That is clear and 
>> deterministic.
>>
>> Subject: [sipcore] I-D Action: 
>> draft-ietf-sipcore-refer-clarifications-00.txt
>>
>>
>> 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.
>>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 01 Dec 2014 15:00:01 -0600

Hi Andrew -

I understand your reasoning, but the text you propose would have to be 
changed if we ever standardized any _other_ way to be sure there is no 
implicit subscription created.

The text in the draft allows the standards to be extended, and does not 
leave the case that you are concerned about open.

RjS

---

From: Adam Roach <[email-masked]>
Date: Mon, 01 Dec 2014 13:05:18 -0800

> Do you ever really know that for certain in the presence of gateways 

Right; this is the real problem. The assumption that this is somehow 
"safe" to do because of some unsignaled, un-negotiated hidden agreement 
is extremely fragile and way outside the various extension mechanisms 
that SIP makes use of.

Walled gardens grow doors. You don't want things to break in spectacular 
and undiagnosable ways when they do. I'm sad that some networks have 
decided to ignore the exact parts of specs that were designed to foster 
interop and prevent these surprise behaviors, and I see dangerous 
precedent in codifying this misbehavior as proposed above.

Walled gardens grow doors faster than you're probably willing to 
believe. I'm frankly astonished by how quickly IMS has turned its eyes 
to WebRTC, asking for special accommodation for features particular to 
3GPP specifications (cf. AMR). That only goes so far: you won't readily 
see JavaScript SIP stacks conforming to this hidden, unnegotiated 
agreement that presumably exists in IMS (but not elsewhere). It's an 
honest-to-goodness protocol fork, an engineered incompatibility.

Walled gardens grow doors. It's time to start cleaning up the IMS garden 
to match SIP behavior, rather than handing out indulgences for its past 
sins.

You're trying to fix this in the wrong SDO.

/a

---

From: Andrew Allen <[email-masked]>
Date: Mon, 1 Dec 2014 23:18:34 +0000

Robert

My concern is that Ivo and Peter who represent two major vendors of SIP based network equipment have a different interpretation to what the current text means.  Doesn't the update process allow us to address that concern in the event that we come up with another mechanism to guarantee that no implicit subscription is created?

Alternatively I would propose we modify the text in question as follows to take the future extension possibility into account:

   A user agent can be certain that no implicit subscription will be
   created as a result of sending a REFER request by using the
   extension in [I-D.ietf-sipcore-refer-explicit-subscription] to 
   require the UAS not to create an implicit subscription. Only 
   when using the explicit subscription mechanism to require that
   a subscription not be created or using a future specified mechanism 
   defined in a standards track RFC that guarantees no implicit 
   subscription will be created MAY the REFER request 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].

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Monday, December 01, 2014 4:00 PM
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi Andrew -

I understand your reasoning, but the text you propose would have to be changed if we ever standardized any _other_ way to be sure there is no implicit subscription created.

The text in the draft allows the standards to be extended, and does not leave the case that you are concerned about open.

RjS

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 2 Dec 2014 09:55:42 +0000

Hi,

The specific environment is described in 3GPP TS 24.237. For the specific case, both ends of the signaling comply to this spec, both ends of the signaling are network nodes. These network nodes either reside in the same network, or reside in different networks, and in this case there would be some sort of agreement between the operators. 

At the time when the solution in 24.237 was designed (pointed at in Ivo's proposal), there was no IETF solution available. So I guess it would be great if the draft does not make the existing solution invalid.

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 2 Dec 2014 10:39:21 +0000

> What criteria do you use to be *certain*?

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 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.

Works.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 1. prosince 2014 19:17
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

I gather that what you have in mind is that both ends have been verified to conform to particular versions of the IMS specification. Do you ever really know that for certain in the presence of gateways to foreign devices?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 11:09:16 +0000

Hi Adam,

Regarding WebRTC, 3GPP does not mandate SIP JavaScript stacks to support IMS SIP extensions and "hidden, unnegotiated agreements" in order to access IMS. In fact, 3GPP doesn't even mandate usage of SIP, it has has taken the same signaling-protocol-is-outside-the-scope approach as IETF.

And, the use-cases we are discussing in this thread would never impact a JavaScript application. They are related to procedures for handover of a call between IMS and circuit switched network.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 1. joulukuuta 2014 23:05
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

> Do you ever really know that for certain in the presence of gateways 

Right; this is the real problem. The assumption that this is somehow "safe" to do because of some unsignaled, un-negotiated hidden agreement is extremely fragile and way outside the various extension mechanisms that SIP makes use of.

Walled gardens grow doors. You don't want things to break in spectacular and undiagnosable ways when they do. I'm sad that some networks have decided to ignore the exact parts of specs that were designed to foster interop and prevent these surprise behaviors, and I see dangerous precedent in codifying this misbehavior as proposed above.

Walled gardens grow doors faster than you're probably willing to believe. I'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, asking for special accommodation for features particular to 3GPP specifications (cf. AMR). That only goes so far: you won't readily see JavaScript SIP stacks conforming to this hidden, unnegotiated agreement that presumably exists in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an engineered incompatibility.

Walled gardens grow doors. It's time to start cleaning up the IMS garden to match SIP behavior, rather than handing out indulgences for its past sins.

/a

---

From: Brett Tate <[email-masked]>
Date: Wed, 3 Dec 2014 08:49:15 -0500

> Walled gardens grow doors. You don't want things to break
> in spectacular and undiagnosable ways when they do.

Draft-kaplan-dispatch-gruu-problematic highlights some of the spectacular
ways things can break when using GRUU.  For instance when generating a
GRUU, how do you know that it is globally routable by every device which
can receive it?

Concerning RFC 6665, did the working group intentionally decide to make it
so notifiers could not exist within a walled garden without somehow
becoming globally routable?

Thanks,
Brett

---

From: Andrew Allen <[email-masked]>
Date: Wed, 3 Dec 2014 19:21:20 +0000

Maybe the way out of this rat hole is to discuss in the text and allow legacy application usages (similar to the legacy usages for INFO).  So SIP stacks could be considered RFC 6665 compliant with legacy application usages using RFC 4488 and feature tags identifying application specific behavior that ensures that dialog reuse does not occur but that we deprecate such usages for any new applications that are developed and insist on the use of [I-D.ietf-sipcore-refer-explicit-subscription] going forward. 
	
As Christer said:

Is that something we could all agree on as a compromise?

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Tuesday, December 02, 2014 4:56 AM
To: ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 10:17:11 +0000

Hi,

I support Andrew's suggestion.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 3. joulukuuta 2014 21:21
To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

As Christer said:

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Tuesday, December 02, 2014 4:56 AM
To: ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Dec 2014 08:07:25 +0000

Hi,

The compromise described by Andrew would work for me.

Regards
Peter

-----Original Message-----
From: ext Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, December 04, 2014 11:17 AM
To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 3. joulukuuta 2014 21:21
To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

As Christer said:

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Tuesday, December 02, 2014 4:56 AM
To: ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 5 Dec 2014 10:13:54 +0000

This compromise would work for me too.

Kind regards

Ivo

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 Leis, Peter (NSN - DE/Munich)
Sent: 5. prosince 2014 9:07
To: Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: ext Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, December 04, 2014 11:17 AM
To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 3. joulukuuta 2014 21:21
To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

As Christer said:

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Tuesday, December 02, 2014 4:56 AM
To: ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: Andrew Allen <[email-masked]>
Date: Sat, 6 Dec 2014 00:04:30 +0000

Robert, Adam and all

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.

Andrew 

-----Original Message-----
From: Ivo Sedlacek [mailto:[email-masked]] 
Sent: Friday, December 05, 2014 5:14 AM
To: Leis, Peter (NSN - DE/Munich); Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Kind regards

Ivo

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: 5. prosince 2014 9:07
To: Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: ext Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, December 04, 2014 11:17 AM
To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 3. joulukuuta 2014 21:21
To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

As Christer said:

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Tuesday, December 02, 2014 4:56 AM
To: ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Dec 2014 12:37:49 +0000

Hi,

Are people ok with Andrew's suggestion?

Regards,

Christer

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: 6. joulukuuta 2014 2:05
To: Ivo Sedlacek; Leis, Peter (NSN - DE/Munich); Christer Holmberg; ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Robert, Adam and all

Andrew 

-----Original Message-----
From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Friday, December 05, 2014 5:14 AM
To: Leis, Peter (NSN - DE/Munich); Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Kind regards

Ivo

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: 5. prosince 2014 9:07
To: Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: ext Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, December 04, 2014 11:17 AM
To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 3. joulukuuta 2014 21:21
To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

As Christer said:

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Leis, Peter (NSN - DE/Munich)
Sent: Tuesday, December 02, 2014 4:56 AM
To: ext Adam Roach; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

Hi,

Regards
Peter

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, December 01, 2014 10:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Dec 2014 10:22:01 -0600

> 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 deprecat…

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.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Dec 2014 16:57:16 +0000

Hi,

>> 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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 18 Dec 2014 16:46:02 -0600

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Dec 2014 12:51:02 +0000

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."

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...").

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

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.

RjS

On 12/18/14 10:57 AM, Christer Holmberg wrote:
>>> 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.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Dec 2014 08:11:57 -0600

On 12/19/14 6:51 AM, Christer Holmberg wrote:
> 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.
I went looking for that explanation to refresh my memory, but couldn't 
find it quickly. Can you provide a pointer?
> But, instead I suggest to extend the last sentence to:
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Dec 2014 14:09:11 +0000

Hi,

>> 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.
>
> I went looking for that explanation to refresh my memory, but couldn't find it quickly. Can you provide a pointer?

I'll look for it, or Ivo can provide the pointer himself (unless he has left for xmas vacation).

Regards,

Christer

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 22 Dec 2014 07:54:35 +0000

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

Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt
From: Ivo Sedlacek <[email-masked]>
To: Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 2 Dec 2014 10:39:21 +0000
List-Id: SIP Core Working Group <sipcore.ietf.org>

In short:

Works.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 1. prosince 2014 19:17
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

        Thanks,
        Paul