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

From: [email-masked]
Date: Fri, 21 Nov 2014 15:19:18 -0800

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/

---

From: Andrew Allen <[email-masked]>
Date: Fri, 28 Nov 2014 01:04:30 +0000

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

Abstract:

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.

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

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 28 Nov 2014 07:38:15 +0000

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

To

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

Abstract:

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 28 Nov 2014 10:56:46 +0000

Hi,

I have the same view as Ivo.

Regards
Peter

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

Hello,

"Only 

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

To

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

Abstract:

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 28 Nov 2014 15:28:43 +0000

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,

"Only 

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

To

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

Abstract:

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Dec 2014 07:50:21 +0000

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,

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,

"Only 

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

To

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

Abstract: