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

[Andrew Allen <[e-mail]>]

I disagree with this new proposal

How can a UA that acts as a UAS for REFER know that all UACs will request not to create a subscription?

According to RFC 3515

2.4.4 Using SIP Events to Report the Results of the Reference

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


Therefore the ability to create an implicit subscription when accepting a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all UACs

So any UA that supports receiving REFER request MUST be ready to create a subscription and therefore MUST provide a GRUU as a Contact in INVITE requests to ensure that out-of-dialog REFER requests can be sent.

Andrew

From: sipcore [mailto:[e-mail]] On Behalf Of Ivo Sedlacek
Sent: Friday, July 25, 2014 2:49 AM
To: Robert Sparks; [e-mail]
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Thank you for taking my comment into account.

I identified one more issue:

ISSUE 2:

section 3 states:
------------------------
   A UA that supports receiving REFER needs to include a GRUU as a
   Contact in INVITE requests to ensure out-of-dialog REFER requests
   related to this dialog arrive at this UA.
------------------------

The above requirement is unnecessary in case the UA supports receiving only REFER requests sent within an existing dialog, for which the UA is certain that no implicit subscription will be created.

Moreover, the 2nd part of the sentence discusses "out-of-dialog REFER requests related to this dialog" while 1st part discusses just "REFER".

PROPOSAL 2:

The requirement should be modified e.g. as follows:

------------------------
   A UA that supports receiving an out-of-dialog REFER request related to a dialog created by an INVITE request needs to include a GRUU as a
   Contact in the INVITE request to ensure any out-of-dialog REFER requests
   related to a dialog created by the INVITE request arrive at this UA.
------------------------

Kind regards

Ivo Sedlacek


From: Robert Sparks [mailto:[e-mail]]
Sent: 24. července 2014 23:36
To: Ivo Sedlacek; [e-mail]<mailto:[e-mail]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

Yes - thanks for the catch, and sorry for not tweaking that already (should have waited until next week).
I'll send an update soon.

RjS
On 7/24/14, 6:50 AM, Ivo Sedlacek wrote:
Hello,

ISSUE:

section 4 states:
------------------------
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.

   >>>A user agent constructing a REFER request MUST built 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].
------------------------

2nd paragraph of the section 4 states unconditional UA procedure (MUST built it as an out-of-dialog message).
4th paragraph of the section 4 states an option for the UA (If a user agent can be certain ...., the REFER request MAY be sent within an existing dialog).

It is not possible to create a UA which would use the option described in 4th paragraph and still be compliant to the statement in 2nd paragraph.

PROPOSAL:

The 2nd paragraph should be conditioned by a condition opposite to the one in the 4th paragraph.

I.e. 2nd paragraph should be conditioned by "Unless 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),"

Kind regards

Ivo Sedlacek


From: sipcore [mailto:[e-mail]] On Behalf Of Robert Sparks
Sent: 22. července 2014 0:24
To: [e-mail]<mailto:[e-mail]>
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-02.txt

This fixed the missing slide 3 text.

RjS


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

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

Date:

Mon, 21 Jul 2014 15:22:39 -0700

From:

[e-mail]<mailto:[e-mail]>

To:

Robert Sparks <[e-mail]><mailto:[e-mail]>, "Adam Roach" <[e-mail]><mailto:[e-mail]>, Adam Roach <[e-mail]><mailto:[e-mail]>, "Robert Sparks" <[e-mail]><mailto:[e-mail]>



A new version of I-D, draft-sparks-sipcore-refer-clarifications-02.txt

has been successfully submitted by Robert Sparks and posted to the

IETF repository.



Name:          draft-sparks-sipcore-refer-clarifications

Revision:      02

Title:         Clarifications for the use of REFER with RFC6665

Document date: 2014-07-21

Group:         Individual Submission

Pages:         4

URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-02.txt

Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/

Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-02

Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-02



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