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

[Mary Barnes <[e-mail]>]

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.

On Tue, Aug 31, 2010 at 10:34 AM, Worley, Dale R (Dale)
<[e-mail]> wrote:
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Hadriel Kaplan [[e-mail]]
>
> 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.
> ______________________________________________
>
> 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
>