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

[Mary Barnes <[e-mail]>]

Hi Hadriel,

Yes, this is confusing (part of the fundamental problem).  Responses
inline below [MB].

Thanks,
Mary.

On Wed, Aug 25, 2010 at 6:03 PM, sipcore issue tracker
<[e-mail]> wrote:
> #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,
>
[MB] Correct. [/MB]

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

[MB] Yes. [/MB]
>
>  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.

[MB] I really, really don't want to use the term divert.  I will
revisit the text and see where all we are using retarget - it may be
better to describe/define in terms that match the tags and thus be
much more explicit.   [/MB]
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/2>
> sipcore <http://tools.ietf.org/sipcore/>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>