--- 1/draft-ietf-sipcore-refer-clarifications-02.txt	2015-03-03 09:14:40.102955333 -0800
+++ 2/draft-ietf-sipcore-refer-clarifications-03.txt	2015-03-03 09:14:40.118955719 -0800
@@ -1,19 +1,19 @@
 
 Network Working Group                                          R. Sparks
 Internet-Draft                                                    Oracle
 Updates: 3515 (if approved)                                     A. Roach
 Intended status: Standards Track                                 Mozilla
-Expires: August 3, 2015                                 January 30, 2015
+Expires: September 4, 2015                                 March 3, 2015
 
             Clarifications for the use of REFER with RFC6665
-               draft-ietf-sipcore-refer-clarifications-02
+               draft-ietf-sipcore-refer-clarifications-03
 
 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.
 
 Status of This Memo
@@ -24,21 +24,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on August 3, 2015.
+   This Internet-Draft will expire on September 4, 2015.
 
 Copyright Notice
 
    Copyright (c) 2015 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -141,23 +141,24 @@
    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, and user agents accepting
    REFER MUST be able to process that extension in requests they
    receive.
 
    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].
+   MAY be sent within an existing dialog (whether or not the remote
+   target is a GRUU).  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].
 
    As described in section 4.5.2 of [RFC6665], there are cases where a
    user agent may fall back to sharing existing dialogs for backwards-
    compatibility purposes.  This applies to REFER only when the peer has
    not provided a GRUU as its Contact in the existing dialog (i.e. when
    the peer is a pre-RFC6665 implementation).
 
 5.  Security Considerations
 
    This document introduces no new security considerations directly.
@@ -172,27 +173,32 @@
 
    Christer Holmberg provided the formulation for the final paragraph of
    the introduction.  Christer Holmberg and Ivo Sedlacek provided
    detailed comments during working group discussion of the document.
 
 8.  Changelog
 
    RFC Editor - please remove this section when formatting this document
    as an RFC
 
-      -02 to -01
+      -02 to -03
+
+         Reinforced that the MAY send in-dialog applied no matter what
+         the remote target URI contained.
 
+      -01 to -02
          Tweaked the third paragraph of section 3 per list discussion.
          (Note the subject line of that discussion said -explicit-
          subscription)
 
       -00 to -01
+
          Added the 3rd paragraph to the introduction per extensive list
          discussion
 
       draft-sparks-sipcore-refer-clarifications-05 to draft-ietf-
       sipcore-refer-clarifications-00
 
          Attempted to improve the accuracy of the Abstract and
          Introduction without diluting the essential point of the
          document.