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

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 07 Aug 2014 13:38:03 +0900

Hi,

>3.  Use of GRUU is mandatory
>
> Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to
> implement and use as the local target in the subscription created by
> the REFER request.

IIUC, RFC6665 requires only notifiers to implement GRUU.

> A user agent constructing any REFER that can result in an implicit
> subscription MUST populate its Contact header field with a GRUU.

Notifiers populate in Contact header of 2xx response for REFER
and NOTIFY request with a GRUU.

> As RFC6665 details, this is necessary to ensure that NOTIFY requests
> sent in the implicitly created subscription arrive at this user agent
> without creating a second usage inside an existing dialog.  Using the

RFC6665 details,
      Because GRUUs are guaranteed to route to a specific device, this
      ensures that the subscription will be routed to the same place as
      the established dialog.

NOTIFY request is sent in dialog, any GRUU is not necessary for
a notifier.

> "norefersub" option tag [RFC4488] does not change this requirement,
> even if used in a "Require" header field.  Even if the recipient
> supports the "norefersub" mechanism, and accepts the request with the
> option tag in the "Require" header field, it is allowed to return a
> "Refer-Sub" header field with a value of "true" in the response, and
> create an implicit subscription.

Because GRUU is used just to receive REFER request, "norefersub" option
is irrelevant.

> In general, UAs that support receiving REFER requests need to include
> a GRUU in the Contact header field of all INVITE requests.  This
> ensures that out-of-dialog REFER requests corresponding to any
> resulting INVITE dialogs are routed to the correct user agent.  UAs
> that will never create a implicit subscription in response to a REFER
> (that is, those that will reject any REFER that might result in an
> implicit subscription) are exempted from this behavior.
>
>4.  Dialog reuse is prohibited
>
> As a direct consequence of requiring the use of GRUU, and the
> requirements in section 4.5.2 of RFC6665, sending a REFER that might
> result in an additional dialog usage within any existing dialog is
> prohibited.

But if notifier is not support GRUU, RFC6665 allosws for flexibility.

> A user agent constructing a REFER request that could result in an
> implicit subscription MUST build it as an out-of-dialog message as
> defined in [RFC3261].  Thus, the REFER request will have no tag
> parameter in its To: header field.
>
> A user agent wishing to identify an existing dialog (such as for call
> transfer as defined in [RFC5589] MUST use the "Target-Dialog"
> extension defined in [RFC4538] to do so.
>
> If a user agent can be certain that no implicit subscription will be
> created as a result of sending a REFER request (such as by requiring
> an extension that disallows any such subscription), the REFER request
> MAY be sent within an existing dialog.  Such a REFER will be
> constructed with its Contact header field populated with the dialog's
> Local URI as specified in section 12 of [RFC3261].

A simplest solution I think is to ignore section 4.5.1.
There is no problem in backward compatibility.

Or someone writes new draft that relaxes the GRUU requirement.

Regards,
Shinji

-------- Original Message --------
> Adam and I spent some time today editing to account for the discussion.
>We believe we covered all the concerns raised.
>
>The sentence in section 3 was getting a bit complex, so we split it up into 
>several.
>Here's what it was before splitting it up:
>
>A UA that will accept a subscription-creating REFER request needs to include
>a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER 
>requests
>related to any dialog created by the INVITE arrive at this UA.
>
>You can see what it turned into by looking in the draft.
>
>RjS
>
>
>-------- Original Message -------- Subject: New Version Notification for 
>draft-sparks-sipcore-refer-clarifications-03.txt
> Date: Mon, 28 Jul 2014 15:16:04 -0700
> From: [a:mailto:[email-masked]][email-masked]
> To: Robert Sparks [a:mailto:[email-masked]]<[email-masked]>, "Adam Roach" 
>[a:mailto:[email-masked]]<[email-masked]>, Adam Roach [a:mailto:
>[email-masked]]<[email-masked]>, "Robert Sparks" [a:mailto:RjS@nostrum.
>com]<[email-masked]>
>
>
>A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt
>has been successfully submitted by Robert Sparks and posted to the
>IETF repository.
>
>Name:		draft-sparks-sipcore-refer-clarifications
>Revision:	03
>Title:		Clarifications for the use of REFER with RFC6665
>Document date:	2014-07-28
>Group:		Individual Submission
>Pages:		4
>URL:            [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-
>refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-sparks-
>sipcore-refer-clarifications-03.txt
>Status:         [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-
>refer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-
>refer-clarifications/
>Htmlized:       [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-
>clarifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-
>clarifications-03
>Diff:           [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-
>refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore
>-refer-clarifications-03
>
>Abstract:
>   An accepted SIP REFER method creates an implicit subscription using
>   the SIP-Specific Event Notification Framework.  That framework was
>   revised by RFC6665.  This document highlights the implications of the
>   requirement changes in RFC6665, and updates the definition of the
>   REFER method, RFC3515, to clarify and disambiguate the impact of
>   those changes.
>
>                                                                               
>   
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

---

From: Robert Sparks <[email-masked]>
Date: Thu, 07 Aug 2014 12:54:45 -0500

I've spent quite some time trying to understand the push for the 
proposal below, and I really think there's confusion, so I'm going to 
try to step up a level and see if we can make progress there.

A UA such as your proposed exception clause describes is simply not a 
compliant 6665 implementation which is what this clarification document 
is about.
If it accepts in-dialog subscription creating REFERs it is following 
3265, not 6665 - further it is violating a 6665 requirement.
If it accepts no REFERs whatsoever, then it's not affected by this document.

If the point of the wordsmithing is to make legacy implementations 
compliant with 6665, there's no way to succeed - they simply aren't.

If that's not the point of the wordsmithing, what is?

At the moment, I think what I sent below is still the right path forward.

RjS

On 8/1/14, 1:44 AM, Ivo Sedlacek wrote:
>
> Any comments on the proposal below?
>
> Kind regards
>
> Ivo Sedlacek
>
> If a REFER request is accepted (that is, a 2xx class response is
>
> returned), the recipient MUST create a subscription and send
>
> notifications of the status of the refer as described in Section
>
> 2.4.4.*From:*sipcore [mailto:[email-masked]] *On Behalf Of 
> *Ivo Sedlacek
> *Sent:* 31. července 2014 9:26
> *To:* Robert Sparks; Andrew Allen; Adam Roach; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [sipcore] Fwd: New Version Notification for 
> Hello,
> According to the draft, the purpose of GRUU in Contact of INVITE 
> request to "
>    resulting INVITE dialogs arrive at this UA."
>
> If a UA rejects any out-of-dialog REFER requests corresponding to any 
> dialogs related to an INVITE request, then setting up GRUU in Contact 
> of INVITE does not provide any purpose.
>
> This is true __regardless__ whether the UA supports and use the 
> draft-sparks-sipcore-refer-explicitsub.
>
> See attached mail giving an example of UA having two types of 
> sessions, Type_A transferrable by REFER, and Type_B not transferrable 
> by REFER.
>
> Given that different standardization organization has defined so many 
> enablers which can run on a single UA, I find it weird that one can 
> guarantee that the above cannot occur.
>
> Thus, I hesitate to mandate an unnecessary requirement influencing 
> possible existing UA implementations and I prefer to be explicit on 
> the exception for usage of GRUU in Contact of INVITE request:
>
>   
>     A UA that will accept a REFER request needs to include
>     resulting INVITE dialogs arrive at this UA.>>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request
>     are exempted from including a GRUU in the Contact header field of the INVITE request.<<<
>
> Kind regards
>
> Ivo Sedlacek
>
> *From:*Robert Sparks [mailto:[email-masked]]
> *Sent:* 30. července 2014 18:54
> *To:* Andrew Allen; Adam Roach; Ivo Sedlacek; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [sipcore] Fwd: New Version Notification for 
> On 7/30/14, 10:33 AM, Andrew Allen wrote:
>
>     I have a general concern with the direction this is now going.
>
> I don't think you have the backwards-compatibility concern quite 
> right, but I agree that the current wording isn't there yet.
>
> Are we now saying here that it’s OK for a UA that supports receiving 
> REFER to arbitrarily reject any REFER that would create a subscription 
> (i.e be incompatible with RFC 3515 UACs by basically not supporting 
> RFC 3515 UAS compliant behavior)?
>
> No, _this_ document is not defining new behavior. It's only clarifying 
> what's already defined.
>
> According to RFC 3515
>
> 2.4.4 Using SIP Events to Report the Results of the Reference
>
>              The NOTIFY mechanism defined in [2] MUST be used to 
> inform the agent sending the REFER of the status of the reference.
>
> Therefore the ability to create an implicit subscription when accepting
>
> FWIW, Accepting is the key word here.
>
> a REFER is mandatory behavior in RFC 3515 and is expected to be 
> supported by all RFC 3515 UACs
>
> I think before agreeing any wording here we should have a general 
> discussion on the principle of whether these extensions that allow 
> UACs to request that no implicit subscription can be effectively 
> required by REFER UAS to be supported at the UAC.
>
> This, and what you have below, is a discussion we definitely need to 
> have as part of the extension document.
> It is not necessary to wait for that discussion to complete the 
> clarifications document that talks about what the specs say _now_.
>
> My discomfort with the current text is that we've made it complex to 
> make it so that we don't have to update the document once the proposed 
> extensions exist.
> There are NO currently standardized cases where the exemption in the 
> current text would be invoked, and I don't think people are trying to 
> argue there are - I'm hearing that to get there, they expect to invoke 
> the yet-to-be-defined extension.
>
> So, lets go back to the slightly longer sentence that led to this:
>
> a GRUU as the Contact in all INVITE requests to ensure out-of-dialog 
> REFER requests
> In an attempt to be future-proof, that's introducing the potential for 
> confusion about what the current standards define.
> Let's remove that confusion.
> Here's a proposed replacement, taking Adam's sentence simplification 
> into account:
>
>    A UA that will accept a REFER request needs to include
>    resulting INVITE dialogs arrive at this UA. Future extensions
>    [draft-sparks-sipcore-refer-explicitsub] might relax this requirement
>    by defining a REFER request that cannot create an implicit 
> subscription.
>
>
> Unless I hear objection soon, I'll rev the draft with that content.
>
> If so then I think we will need a new sip options tag (e.g 
> REFER-NOSUB) to be used in place of the REFER options tag so that a 
> RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of 
> a REFER and that includes an Accept-Contact request to reach a UA that 
> supports REFER doesn’t end up at a UAS that doesn’t  support compliant 
> RFC 3515 behavior and ends up having its REFER requests rejected.
>
> My own view is that we should keep with the principle of backward 
> compatibility and that even when these no automatic subscription 
> extensions are supported that full support for RFC 3515 behavior is 
> continued.
>
> Andrew
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Adam Roach
> *Sent:* Tuesday, July 29, 2014 11:19 AM
> *To:* Ivo Sedlacek; Robert Sparks; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [sipcore] Fwd: New Version Notification for 
> On 7/29/14 09:52, Ivo Sedlacek wrote:
>
>     Thus, the text should state:
>
>        In general, UAs that support receiving >>and accepting an
>     out-of-dialog<< REFER request >>corresponding to a dialog
>     established by an INVITE request<< need to include
>
>        a GRUU in the Contact header field of >>the<< INVITE request.  This
>
> I helped with the phrasing here, and one of the goals here was to make 
> the first sentence cover the vast majority of the cases (hence "in 
> general"), with the exceptional cases described later. The problem was 
> that the overall concept was getting lost in a maze of twisty clauses: 
> the clarification had become worse than the source text; it was 
> actually more confusing.
>
> Your proposal returns it to this very confusing state, and is way, way 
> out into the realm of exceptional cases.
>
> So I'll counterpropose:
>
>     that will not create a implicit subscription in response to a REFER
>     for the resulting dialog(s) -- that is, those that will reject a
>     corresponding REFER that might result in an implicit subscription --
>     are exempted from this behavior.
>
>
> /a
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 12 Aug 2014 07:24:03 +0000

Hello,

There still seems to be misunderstanding. Let me state my issue in a different and more general way:

If:
- a UE supports receiving and accepting of out-of-dialog REFER request related to dialogs created by some (but not all) INVITE requests; and
- for a particular INVITE request, the UA rejects any out-of-dialog REFERs related to dialogs created by the particular INVITE request;
should the UE be still mandated to put GRUU in the Contact of the particular INVITE request? If so, what will the GRUU be used for?

Please note that the question above focuses solely on out-of-dialog REFERs.

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: 7. srpna 2014 19:55
To: Ivo Sedlacek; Andrew Allen; Adam Roach; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

I've spent quite some time trying to understand the push for the proposal below, and I really think there's confusion, so I'm going to try to step up a level and see if we can make progress there.

A UA such as your proposed exception clause describes is simply not a compliant 6665 implementation which is what this clarification document is about.
If it accepts in-dialog subscription creating REFERs it is following 3265, not 6665 - further it is violating a 6665 requirement.
If it accepts no REFERs whatsoever, then it's not affected by this document.

If the point of the wordsmithing is to make legacy implementations compliant with 6665, there's no way to succeed - they simply aren't.

RjS

Kind regards

Ivo Sedlacek

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

Hello,

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

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

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

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

   resulting INVITE dialogs arrive at this UA. >>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request

Kind regards

Ivo Sedlacek

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

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

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

According to RFC 3515

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

Therefore the ability to create an implicit subscription when accepting
FWIW, Accepting is the key word here.
a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs

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

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

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

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

   by defining a REFER request that cannot create an implicit subscription.

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

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

Andrew

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

   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include

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

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

So I'll counterpropose:

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 12 Aug 2014 08:52:16 +0000

(extended with my answer on the question and the proposed draft text)

Hello,

If:

IMO, answer to the questions above is:

            The UE should not be mandated to put GRUU in Contact of the particular INVITE request, since any out-of-dialog REFER request related to any dialog created by the particular INVITE request is rejected. Thus, the GRUU does not provide any value.

Therefore, the draft should state:
-----------------------
A UA that will accept a subscription-creating REFER request >>related to a dialog of an INVITE request<< needs to include
a GRUU as the Contact in >>the<< INVITE request to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE >>request<< arrive at this UA.
-----------------------

Kind regards

Ivo Sedlacek

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

RjS

Kind regards

Ivo Sedlacek

Hello,

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

So I'll counterpropose:

/a

---

From: Andrew Allen <[email-masked]>
Date: Tue, 12 Aug 2014 12:48:24 +0000

Re-engaging in this thread after  taking some vacation time.

In my view if we accept the concept  that a UAS has a policy not to accept any REFER that would create an implicit subscription that means we accept the concept that UAS that support REFER method  don’t interoperate (and therefore are not backwards compatible with) basic RFC 3515 UACs that don’t support the new extensions. IMHO that is not a road we ought to go down.

Andrew

From: Robert Sparks [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 12:54 PM
To: Andrew Allen; Adam Roach; Ivo Sedlacek; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

According to RFC 3515

Andrew

So I'll counterpropose:

/a

---

From: Andrew Allen <[email-masked]>
Date: Tue, 12 Aug 2014 12:52:57 +0000

What reason would a UAC have such a restriction for some and not others?

Why would it be advantageous to  decrease interoperability in such situations?

Whether the REFER request is sent within or outside the dialog should be a UAC decision (if its RFC 3515 only compliant) and outside the dialog if is also RFC 6665 compliant.

Andrew

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Tuesday, August 12, 2014 3:24 AM
To: Robert Sparks; Andrew Allen; Adam Roach; [email-masked]
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hello,

If:

Kind regards

Ivo Sedlacek

RjS

Kind regards

Ivo Sedlacek

Hello,

Kind regards

Ivo Sedlacek

According to RFC 3515

Andrew

So I'll counterpropose:

/a

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 12 Aug 2014 23:38:47 +0900

Hi,

I have another question.

If 6665 compliant UAS receives a REFER request within an
existing dialog that would create an implicit subscription,
how should the UAS handle the REFER request?

Regards,
Shinji

>URL:            [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt
>Status:         [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/
>Htmlized:       [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03
>Diff:           [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03
>
>Abstract:

---

From: Robert Sparks <[email-masked]>
Date: Tue, 12 Aug 2014 09:59:24 -0500

So, I think we're getting closer to the disconnect.

Your posited UA is going to reject out-of-dialog refers (at least in the 
context of a given dialog).
Is it going to reject all refers? If so, 3515 (updated by 6665) doesn't 
apply to its behavior during this dialog.
So, I'm assuming you are specifically interested in the case where it 
accepts in-dialog refers.

If your UA provided a GRUU when it started the dialog, and the far end 
is satisfying the requirements of 6665, it would not send you an 
in-dialog REFER. It would be violating a MUST NOT to do so.

If your UA did not provide a GRUU, it is (in the context of this dialog) 
not satisfying the requirements of 6665. It's acting like a pre-6665 
implementation, at least in the context of that dialog. If the far end 
is 6665 compliant, it has the option (as specified in 6665 section 
4.5.2) to fall back to dialog-reuse. I think this, perhaps, is what 
you're trying to get the text to reflect.

If the far end is not 6665 compliant, it's effectively two old 
implementations talking to each other and this document doesn't apply.

The text you're proposing (if I've got it right) is trying to say "this 
UA is not using 6665 in the context of this dialog".
As long as it is behaving that way, this document does not apply, and 
the tension comes from trying to talk about such things in this document.

I also don't think you're really concerned about UAs that will decide, 
when sending an INVITE request, that they're going to be 6665 compliant 
on some and not some others. Let me know if I'm wrong - we need to have 
a different conversation than what's below.

Rather, I suspect you're concerned about a population of pre-6665 UAs 
that always won't. The more interesting question is what 6665 capable 
UAs do when _accepting_ offered INVITE dialogs where the peer has not 
provided a GRUU. If they are 6665 compliant, they have the fallbacks 
available to them from section 4.5.2 on accepting in dialog 
subscriptions, but 6665 should discuss whether they should provide a 
GRUU for their local contact in response to the INVITE, and it should 
explicitly talk about all subscriptions in either direction falling 
under 5.4.2. That's a job for the update to RFC 6665 that Adam has 
signed up for, not this document.

What this document _can_ do is speak more concretely and correctly in 
terms of things that the document applies to.
The changes will touch a couple of the paragraphs in section 4, and I 
think trying to follow the diffs in email is going to get dicey, so I'll 
drop a revision of the draft with them so rfcdiff can help.

RjS

On 8/12/14, 3:52 AM, Ivo Sedlacek wrote:
> - a UE supports receiving and accepting of out-of-dialog REFER request 
> related to dialogs created by _some (but not all)_ INVITE requests; and
>
> - for _a particular INVITE request_, the UA rejects any out-of-dialog 
> REFERs related to dialogs created by the particular INVITE request;
>
> should the UE be still mandated to put GRUU in the Contact of _the 
> particular INVITE request_? If so, what will the GRUU be used for?
>
> The UE should not be mandated to put GRUU in Contact of the 
> _particular INVITE request_, since any out-of-dialog REFER request 
> related to any dialog created by the _particular INVITE request_is 
> rejected. Thus, the GRUU does not provide any value.
>
> A UA that will accept a subscription-creating REFER request >>related 
> to a dialog of an INVITE request<< needs to include
>
> *Sent:* 7. srpna 2014 19:55
> *To:* Ivo Sedlacek; Andrew Allen; Adam Roach; [email-masked] 
> compliant 6665 implementation which is what this clarification 
> document is about.
>     2.4.4.*From:*sipcore [mailto:[email-masked]] *On Behalf
>     Of *Ivo Sedlacek
>     If a UA rejects any out-of-dialog REFER requests corresponding to
>     any dialogs related to an INVITE request, then setting up GRUU in
>     Contact of INVITE does not provide any purpose.
>
>     sessions, Type_A transferrable by REFER, and Type_B not
>     transferrable by REFER.
>
>     Given that different standardization organization has defined so
>     many enablers which can run on a single UA, I find it weird that
>     one can guarantee that the above cannot occur.
>
>     possible existing UA implementations and I prefer to be explicit
>     on the exception for usage of GRUU in Contact of INVITE request:
>
>       
>
>     Are we now saying here that it’s OK for a UA that supports
>     receiving REFER to arbitrarily reject any REFER that would create
>     a subscription (i.e be incompatible with RFC 3515 UACs by
>     basically not supporting RFC 3515 UAS compliant behavior)?
>
>     This, and what you have below, is a discussion we definitely need
>     to have as part of the extension document.
>     My discomfort with the current text is that we've made it complex
>     to make it so that we don't have to update the document once the
>     proposed extensions exist.
>     There are NO currently standardized cases where the exemption in
>     the current text would be invoked, and I don't think people are
>     trying to argue there are - I'm hearing that to get there, they
>     expect to invoke the yet-to-be-defined extension.
>
>     In an attempt to be future-proof, that's introducing the potential
>     for confusion about what the current standards define.
>     REFER-NOSUB) to be used in place of the REFER options tag so that
>     a RFC 3515 compliant UA that expects a NOTIFY to be sent upon
>     receipt of a REFER and that includes an Accept-Contact request to
>     reach a UA that supports REFER doesn’t end up at a UAS that
>     doesn’t  support compliant RFC 3515 behavior and ends up having
>     its REFER requests rejected.
>
>     extensions are supported that full support for RFC 3515 behavior
>     is continued.
>
>     Andrew
>
>     I helped with the phrasing here, and one of the goals here was to
>     make the first sentence cover the vast majority of the cases
>     (hence "in general"), with the exceptional cases described later.
>     The problem was that the overall concept was getting lost in a
>     maze of twisty clauses: the clarification had become worse than
>     the source text; it was actually more confusing.
>
>     Your proposal returns it to this very confusing state, and is way,
>     way out into the realm of exceptional cases.
>
>     So I'll counterpropose:
>

---

From: Andrew Allen <[email-masked]>
Date: Tue, 12 Aug 2014 17:38:31 +0000

I think that's clear. The RFC 6665 UAC acts as per RFC 3515.  See RFC 6665 4.2.1

----- Original Message -----
From: OKUMURA Shinji [mailto:[email-masked]]
Sent: Tuesday, August 12, 2014 10:38 AM Eastern Standard Time
To: [email-masked] <[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hi,

I have another question.

Regards,
Shinji

>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: Andrew Allen <[email-masked]>
Date: Tue, 12 Aug 2014 17:52:44 +0000

I meant UAS not UAC

----- Original Message -----
From: OKUMURA Shinji [mailto:[email-masked]]
Sent: Tuesday, August 12, 2014 10:38 AM Eastern Standard Time
To: [email-masked] <[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hi,

I have another question.

Regards,
Shinji

---

From: Robert Sparks <[email-masked]>
Date: Tue, 12 Aug 2014 14:19:06 -0500

The rev is up, and the diff is available at
<http://www.ietf.org/rfcdiff?url1=draft-sparks-sipcore-refer-clarifications-03&difftype=--html&submit=Go!&url2=draft-sparks-sipcore-refer-clarifications-04>

On 8/12/14, 9:59 AM, Robert Sparks wrote:
> Your posited UA is going to reject out-of-dialog refers (at least in 
> the context of a given dialog).
> Is it going to reject all refers? If so, 3515 (updated by 6665) 
> doesn't apply to its behavior during this dialog.
> If your UA did not provide a GRUU, it is (in the context of this 
> dialog) not satisfying the requirements of 6665. It's acting like a 
> pre-6665 implementation, at least in the context of that dialog. If 
> the far end is 6665 compliant, it has the option (as specified in 6665 
> section 4.5.2) to fall back to dialog-reuse. I think this, perhaps, is 
> what you're trying to get the text to reflect.
>
> The text you're proposing (if I've got it right) is trying to say 
> "this UA is not using 6665 in the context of this dialog".
> when sending an INVITE request, that they're going to be 6665 
> compliant on some and not some others. Let me know if I'm wrong - we 
> need to have a different conversation than what's below.
>
> think trying to follow the diffs in email is going to get dicey, so 
> I'll drop a revision of the draft with them so rfcdiff can help.
>
> RjS
>
>> - a UE supports receiving and accepting of out-of-dialog REFER 
>> request related to dialogs created by _some (but not all)_ INVITE 
>> requests; and
>>
>>     *Sent:* 31. c(ervence 2014 9:26
>>     Thus, I hesitate to mandate an unnecessary requirement
>>     influencing possible existing UA implementations and I prefer to
>>     be explicit on the exception for usage of GRUU in Contact of
>>     INVITE request:
>>
>>       
>>
>>     *Sent:* 30. c(ervence 2014 18:54
>>     Are we now saying here that it's OK for a UA that supports
>>     discussion on the principle of whether these extensions that
>>     allow UACs to request that no implicit subscription can be
>>     effectively required by REFER UAS to be supported at the UAC.
>>
>>     In an attempt to be future-proof, that's introducing the
>>     potential for confusion about what the current standards define.
>>     reach a UA that supports REFER doesn't end up at a UAS that
>>     doesn't  support compliant RFC 3515 behavior and ends up having
>>     Your proposal returns it to this very confusing state, and is
>>     way, way out into the realm of exceptional cases.
>>
>>     So I'll counterpropose:
>>

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 13 Aug 2014 07:25:30 +0000

Hello,

> Your posited UA is going to reject out-of-dialog refers (at least in the context of a given dialog).
> Is it going to reject all refers? 

If you meant REFERs related to dialogs created by the particular INVITE request, then:
- the UA rejects any out-of-dialog REFERs related to dialogs created by the particular INVITE request as stated in the question below; and
- the UA handles any in-dialog REFER received in a dialog created by the particular INVITE request according to RFC6665. The UA rejects any in-dialog REFER request that would result in an implicit subscription.

If you also meant REFERs related to dialogs created by other INVITE request, then UA can accept or reject them within rules given by RFC6665.

> If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665. 
> ...
> The text you're proposing (if I've got it right) is trying to say "this UA is not using 6665 in the context of this dialog".

Can you please quote the RFC6665 requirement which the UA does not satisfy?

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 13 Aug 2014 11:09:10 +0000

> What reason would a UAC have such a restriction for some and not others? 

There are a lot of SIP enablers defined by different SDOs which use INVITE request and which can be supported in the same UA. 

Why should the UE be mandated to accept a REFER related to a session of every single enabler?

> Why would it be advantageous to  decrease interoperability in such situations?

Everything works so the interoperability is not decreased.

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Aug 2014 09:26:06 -0500

> - the UA handles any in-dialog REFER received in a dialog created by the particular INVITE request according to RFC6665. The UA rejects any in-dialog REFER request that would result in an implicit…
Is this back to norefersub? Is your argument that you can accept the 
refer because you're the potential notifier and you know you won't take 
the path of norefersub that would create a subscription? If so, we may 
have a box around what we need to cover. If not, say more.

> If you also meant REFERs related to dialogs created by other INVITE request, then UA can accept or reject them within rules given by RFC6665.
No, I was talking the the context of a given dialog.
> Can you please quote the RFC6665 requirement which the UA does not satisfy?
The first sentence of 4.5.1.
The clarification that Adam has signed up for well shine the light on that.
If there is any potential for a UA to become a notifier for _any_ event 
package (not just refer, but think also dialog), it will need to provide 
a GRUU for any dialog it tries to enter.

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 13 Aug 2014 15:03:18 +0000

Hello,

> > - the UA rejects any out-of-dialog REFERs related to dialogs created 
> > by the particular INVITE request as stated in the question below; and
> Is this back to norefersub? Is your argument that you can accept the refer because you're the potential notifier and you know you won't take the path of norefersub that would create a subscription? If so, we may have a box around what we need to cover. If not, say more.

Could we focus on the next question (which seems to be the KEY question) and, after we solved it, return to this one?

> If there is any potential for a UA to become a notifier for _any_ event package (not just refer, but think also dialog), it will need to provide a GRUU for any dialog it tries to enter.

RFC6665, section 4.5.1, 1st sentence states:   

	Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target.

Isn't notifier a role taken in subscription, applicable only for the dialog of the subscription?
The UA does not act as notifier in the dialogs created by the particular INVITE request. 
Thus, in my reading, the requirement does not apply for the particular INVITE request.
Or do I miss anything?

Kind regards

Ivo Sedlacek

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Aug 2014 10:26:59 -0500

> Thus, in my reading, the requirement does not apply for the particular INVITE request.

This is exactly what the document that I'll be producing is going to 
clarify.

For what it's worth, "notifier" is defined in section 2 of 6665, and 
it's not a role.

To the point of the specific section you quote, let's look at the whole 
paragraph:

    Notifiers MUST implement the Globally Routable User Agent URI (GRUU)
    extension defined in [RFC5627], and MUST use a GRUU as their local
    target.  This allows subscribers to explicitly target desired
    devices.

Now, take a moment to think really hard about what the second sentence 
there means. If it's not nonsense or useless noise -- and I assure you 
that it is not -- then it must be referring to the ability to subscribe 
to something on a device that the subscriber already knows exists. In 
order to make that happen, the subscriber must have learned the GRUU 
some way.

How do subscribers learn about GRUUs? It's right there in the first 
sentence: Notifiers include GRUUs as their local target. We'll come back 
to this.

The use cases that make this interesting are those that involve 
subscribing to some information about a dialog that you're already in 
(or were recently in). In fact, not just *any* dialog, but INVITE 
dialogs. So how does this happen?

As I said above: notifers include GRUUs them as their local target. 
Every time. Including INVITE dialogs.

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 13 Aug 2014 15:37:43 +0000

Hello Adam,

Imagine that UA:
- sent NOTIFY to received SUBSCRIBE in dialog X, subscription still exists
- sent SUBSCRIBE and received NOTIFY in dialog Y, subscription still exists
- sent INVITE and received 200 OK in dialog Z, session still exists

Are you stating that the UA performs statement mandated for notifier below also when sending messages in dialog Y and dialog Z? 

    >>Notifiers<< MUST implement the Globally Routable User Agent URI (GRUU)
    extension defined in [RFC5627], and >>MUST use a GRUU as their local
    target. << This allows subscribers to explicitly target desired
    devices.

Seems contrary to RFC6665 definition of notifier:

   Notifier:  A notifier is a user agent that >>generates NOTIFY requests<<
      for the purpose of notifying subscribers of the state of a
      resource.  Notifiers typically also accept SUBSCRIBE requests to
      create subscriptions. 

I agree that the if subscription is possible, subscriber benefits from knowing GRUU of the UA which will become notifier. However, I do not read it from the RFC6665 text above. Maybe my reading is wrong...

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 13. srpna 2014 17:27
To: Ivo Sedlacek; Robert Sparks; Andrew Allen; [email-masked]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

> Thus, in my reading, the requirement does not apply for the particular INVITE request.

This is exactly what the document that I'll be producing is going to clarify.

For what it's worth, "notifier" is defined in section 2 of 6665, and it's not a role.

Now, take a moment to think really hard about what the second sentence there means. If it's not nonsense or useless noise -- and I assure you that it is not -- then it must be referring to the ability to subscribe to something on a device that the subscriber already knows exists. In order to make that happen, the subscriber must have learned the GRUU some way.

How do subscribers learn about GRUUs? It's right there in the first
sentence: Notifiers include GRUUs as their local target. We'll come back to this.

The use cases that make this interesting are those that involve subscribing to some information about a dialog that you're already in (or were recently in). In fact, not just *any* dialog, but INVITE dialogs. So how does this happen?

/a

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Aug 2014 10:42:01 -0500

> Could we focus on the next question (which seems to be the KEY question) and, after we solved it, return to this one?
I think you'll find they're the same question.
> The UA does not act as notifier in the dialogs created by the particular INVITE request.
Specifically the UA is deciding, before it enters a dialog, that it will 
not use SIP events for _any_ event package related to this dialog, and 
is deciding to effectively internally fork all messages for this dialog 
to an implementation that supports neither 3265 nor 6665, right?

 From a protocol perspective (inspecting the messages on the wire), from 
the far end, something that does that is indistinguishable from two UAs 
that have different capabilities and routing across intermediaries 
landed dialog-creating messages on the different UAs. (Andrew, this is 
the best model I've found for discussing the interoperability concern 
you've been expressing.)

That UA that doesn't support 3265 or 6665 (specifically, how the UA you 
posit is behaving for this dialog) is by definition unconcerned with 
what 3265 and 6665 say. It is effectively out-of-scope for _this_ 
document, EXCEPT potentially for the one case I ask about above.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Aug 2014 08:48:59 +0000

Hi,

I may have missed something, but in general a UA can make *per-dialog decisions* (based on configuration, policies, user interaction, use-case etc etc etc) on what capabilities/features it offers to the remote peer.

Why is being a notifier different? If Bob will not accept subscriptions from Alice, why does Bob have to act towards Alice as if he would be willing to accept subscriptions from Alice, just because Bob may accept subscriptions from Lisa? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Aug 2014 11:30:53 +0000

Hi Robert,

>That UA that doesn't support 3265 or 6665 (specifically, how the UA you posit is behaving for this >dialog) is by definition unconcerned with what 3265 and 6665 say. It is effectively out-of-scope for >_this_ document, EXCEPT potentially for the one case I ask about above.

The issue, which seems to cause the confusion, is that the UA still implements 6665 (as it may use it for other dialogs), and the text ssays *ALL* INVITEs. 

It would be more clear if the text talked about INVITEs for dialogs where the 6665 functionality is provided.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Aug 2014 15:42:43 -0500

> Are you stating that the UA performs statement mandated for notifier below also when sending messages in dialog Y and dialog Z?

Yes.

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 15 Aug 2014 08:02:49 +0000

> > Are you stating that the UA performs statement mandated for notifier below

> also when sending messages in dialog Y and dialog Z?

> Yes.

It seems incorrect.

In dialog Y, the UA sent SUBSCRIBE and thus is subscriber.

   Subscriber          Notifier

       |-----SUBSCRIBE---->|     Request state subscription

       |<-------200--------|     Acknowledge subscription

       |<------NOTIFY----- |     Return current state information

       |--------200------->|

       |<------NOTIFY----- |     Return current state information

       |--------200------->|

Kind regards

Ivo Sedlacek