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

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Aug 2010 13:57:43 -0400

Do you not want to use the term "Divert" because of the Diversion header?

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
> <[email-masked]> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 30 Aug 2010 17:27:40 -0500

Responses inline below [MB].

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 Aug 2010 11:34:03 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]

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.
______________________________________________

People use these various terms freely, but in reality, none of them are well-defined and people don't use the same definition for each term.  The current doc carries forward this confusion by deferring the meanings to previous documents.  The only useful way to deal with the situation is to define the terms we want to use ab initio in this document.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Tue, 31 Aug 2010 10:47:37 -0500

If you read my response, my concern is that there is another document
that refers to RFC 4244 that uses the same terminology as RFC 4244 and
yet another document that already defines divert.  So, it's not clear
to me that this wouldn't just add to the confusion.  I'm of the
mindset right now that we should resolve all the other editorial
issues and see if being more precise with the current definitions
doesn't help and just live with the ambiguity as we've lived with it
for other terms.  The important aspect is what happens with the
protocol and I think it's more important to get the normative text
correct.

BTW, it would have been fantastic to have received alot of these
editorial comments a year ago as none of the intro text, etc.  has
changed since the individual -02, published in July 2009.  Indeed, the
majority of the comments are related to RFC4244 text ;)  I certainly
do appreciate the feedback, of course and in the long run the end
result will be much improved, I just want to highlight that it's not
the process per se that's slowing down this work.

Thanks,
Mary.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 Aug 2010 14:36:55 -0400

________________________________________
From: Mary Barnes [[email-masked]]

I'm of the

It seems to me that the definitions of "retargeting", "redirecting", etc. (with the possible exception of "diversion") are not clear and have never been clear.  Up until 4244bis, this hasn't mattered.  But in 4244bis these allegedly distinct operations cause different things to go on the wire, so we have to make the definitions unambiguous.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Tue, 31 Aug 2010 14:39:48 -0500

The intent is that the tags (or lack thereof) are what adds the
clarification.  There's only so much we can do to not avoid conflict
with other terms.  IF we were rewriting RFC 3261, then certainly, we
could resolve this issue.  My suggestion is that we clean up all the
other issues, etc. that folks have highlighted and then we'll see
where we are. It might become more obvious (to me at least) how best
to use the terms as I'm in the middle of the edits.

Mary.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Aug 2010 19:44:09 -0400

+1