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

[Mary Barnes <[e-mail]>]

Responses inline below [MB].

On Mon, Aug 30, 2010 at 12:57 PM, Hadriel Kaplan <[e-mail]> wrote:
>
> Do you not want to use the term "Divert" because of the Diversion header?
[MB] Well, yeah.  But seriously, I don't think the problem is any
worse in this document than in any others.  The term divert is already
defined in the Diversion header historical RFC.  And, the use of the
term retarget as used in RFC 4244 is referenced in other RFCs, so I'm
not sure how much confusion would be cleared up using the term
"divert". [/MB]

>
> I think it's the only term left that isn't ambiguous... "retarget" is being used for any/all cases of changing the request-uri, and "forward" is used for generic message routing procedures, and "redirect" is used for 3xx cases.  So there isn't a term left I can think of that means "changing the target to a new user/identity" (i.e., "call forwarding" in the PSTN).
>
> And really the draft would be clearer if there was a unique term for that, because a lot of use-cses depend on it: finding the previous or current diverted-to party.
>
> -hadriel
>
> On Aug 28, 2010, at 5:12 PM, Mary Barnes wrote:
>
>> 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
>> >
>>
>
>