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

[Ivo Sedlacek <[e-mail]>]

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