[sipcore] #2: Editorial: section 2 is really confusing

["sipcore issue tracker" <[e-mail]>]

#2: Editorial: section 2 is really confusing
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  minor                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 Section 2 "Conventions and terminology" defines two terms: "retarget" and
 "forward".  I can't make heads or tales about what they mean from this
 text, or how they're different.  I went back and read the original RFC
 4424, and in there it was somewhat clearer (section 1.3 and 3 of rfc4424).

 Currently 4424bis says this:
    The term "retarget" is used in this document to refer both to the
    process of a Proxy Server/User Agent Client (UAC) changing a Uniform
    Resource Identifier (URI) in a request based on the rules for
    determining request targets as described in Section 16.5 of [RFC3261]
    and the subsequent forwarding of that request as described in section
    16.6 of [RFC3261].

 I *think* what you mean is this:
    The term "retarget" is used in this document to refer to the
    process of a Proxy Server/User Agent Client (UAC) changing the
    Request-URI of a request, based on the rules for
    determining request targets as described in Section 16.5 of [RFC3261]
    and step-2 of the subsequent forwarding of that request as described in
 section
    16.6 of [RFC3261].  This includes changing the Request-URI due to a
 location service lookup and 3xx redirect processing,

 4424bis then says this about forwarding:
    The term "forward" is used consistent with the terminology in
    [RFC3261].  Noting that [RFC3261] uses the term "forwarding" to
    describe a proxy's handling of requests for domains for which is not
    responsible, as well as to describe the basic "forwarding" of a
    request (in section 16.6) once a target has been determined.
    However, the context of the usage is sufficient to differentiate the
    slightly different meanings.

 This is super-confusing, and not what you meant I think.  At least not the
 "describe a proxy's handling of requests for domains for which is not
 responsible" piece.  The real ambiguity of the term "forward" in 3261 is
 that it's used both for request routing procedures and for "call
 forwarding" to a new user/identity.  Is that what you mean?

 What this 4424bis draft does not have a term for is for when the request
 gets retargeted to a new identity - *that* has been described in previous
 drafts and emails as "retargeting", whereas "rerouting" or "contact
 routing" was changing the req-URI but not the identity.  I suggest you use
 the word "divert" for changing the identity, since "retarget" and
 "redirect" are ambiguous.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/2>
sipcore <http://tools.ietf.org/sipcore/>