This defintion only makes sense when the following definitions are used:
Name:
A name is a moniker for an entity which refers to it in a way which
reveals nothing about where it is in a network. In SIP, tel URI
which doesn't represent the location of the entity is a name.
Address:
An address is an identifier for an entity which describes it by its
location on the network. In SIP, the SIP URI itself is a form of
address because the host part of the URI, the only mandatory part of
the URI besides the scheme itself, indicates the location of a SIP
server that can be used to handle the request.
Route:
Finally, a route is a sequence of SIP entities (including the UA
itself!) which are
traversed in order to forward a request to an address or name.
Retarget (other term might be needed, as this is highly confusing):
A Request-URI rewrite operation that changes the target identity of
the request.
Reroute (other term might be needed):
A Request-URI rewrite operation that does not change the current
target of the request, but determines the route/next hop taken to
reach the target-identity.
/Hans Erik
Mary Barnes wrote:
> So, by "target-uri concept" are you referring to the solution in the
> current target-uri draft or the application usage as such in the
> target-uri document (which is what I was referring to)?
>
> Yes, the problem is that SIP doesn't differentiate the various
> mechanisms by which a request-URI may be changed, which is what some
> of the updated text in 4244bis is trying to do and why we need precise
> terms. I think we all agree that.
>
> I honestly don't care what we call the tag, as long as we're clear
> about the functionality.
>
> Mary.
>
> -----Original Message-----
> From: Hans Erik van Elburg [mailto:
ietf.hanserik at gmail.com]
> Sent: Wednesday, March 11, 2009 4:40 PM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Shida Schubert;
sip at ietf.org
> Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
> The target-uri concept when defined properly is entirely application
> agnostic.
>
> When one uses History-Info or another header as a vehicle for this
> information then it still can be considered application agnostic as
> any application can use this information as it likes.
>
> From SIP perspective all the Request-URI rewrites look the same, that
> is what brought us discussing this in the first place.
>
> /Hans Erik
>
> Mary Barnes wrote:
>
>> And, I think the big issue with the terminology is that 4244bis is
>> application agnostic, so it is tagging what happens to the URIs
>> (why/how the specific URI was overwritten). Whereas, specific
>> applications can derive information, such as what "is" the real
>> "target" for the request, from the History-Info header. So, IMHO,
>> it's a matter of the target-uri document specifying that the last
>> entry tagged by whatever name we come up with "is" the real "target"
>> for the request. I believe it's up to the applications to describe
>> how they make use of the History-Info and not for the History-Info to
>> describe how applications can use it. History-Info purely reflects
>> what happened from a SIP Protocol perspective and should not imply
>> any
>>
>
>
>> application semantics. Indeed the intent of section 5 of 4244 was to
>> inform the applications how they should decribe their usage of the
>> header.
>>
>> Mary.
>> Note: I changed the subject to hopefully make this topic easier to
>> keep track of.
>>
>> ---------------------------------------------------------------------
>> -
>> --
>> *From:* Hans Erik van Elburg [mailto:
ietf.hanserik at gmail.com]
>> *Sent:* Wednesday, March 11, 2009 3:59 AM
>> *To:* Shida Schubert
>> *Cc:*
sip at ietf.org List; Barnes, Mary (RICH2:AR00)
>> *Subject:* Re: [Sip] Fwd: I-D
>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>>
>> One of the problems that made the discussion quite tedious is the
>> complete inversed meaning of the terms "retarget" and "reroute"
>> between 4244bis and target-uri factions have.
>>
>> Conclusion was that the terminology need to be properly defined and
>> some attempt was made to start such activity.
>>
>> On 3. I have strong concerns when we start tagging the URI as to how
>> they come about "retarget"/"mapped conficuration" etc. It is better
>> to
>>
>
>
>> embellish them with a tag that just represents there meaning for
>> example "istarget" or "hop". For the following reasons:
>> 1. It is much more intuitive for the user of this information, its
>> meaning can basically be guessed.
>> 2. Such meaning also probably survives application in other problem
>> spaces that we had not foreseen when introducing the concept.
>>
>> The solution that is described now in the target-URI delivery draft
>> is not yet complete, it does not solve the freephone use case for
>> example and in its current form it will deliver exactly the same
>> target-URI as that which would be delivered by the P-Called-Party-ID
>> header. Contrary to what the draft says. So some work is needed
still.
>>
>> /Hans Erik van Elburg
>>
>>
>> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert <
shida at ntt-at.com
>> <mailto:
shida at ntt-at.com>> wrote:
>>
>>
>> We have submitted the updated target-uri draft based on the
>>
> comments
>
>> submitted to the list and comments received at IETF73.
>>
>> I have taken over as editor as Jonathan didn't have the cycles to
>> update the draft, with Francois, Christer and Hans Erick as
>> additional
>> co-authors and great deal of help from Mary.
>>
>> The following summarizes the changes made to the target-uri
>>
> document
>
>> 1. Added use-case for toll-free number back
>> 2. Added definition of "retarget" operation.
>> 3. Removed a reference to URN
>> 4. Added a text discussing the difference to P-Called-Party-Id
>> 5. Changed parameter name from "target" to "istarget"
>>
>> Note, that the target-uri document still contains the normative
>> text for the
>> History-Info header.
>>
>> In addition, Mary (with Francois as co-author) has submitted a
>> rfc4244bis, with the following changes:
>> 1. Incorporated the normative aspects of the target-uri document
>> into the existing normative text in RFC 4244 - the functionality
>>
> is
>
>> virtually identical (as is some of the text) as the HI based
>>
> solution
>
>> described in the target-uri document. It's important that the
>> solution
>> be integrated into RFC 4244 as it MUST work and be based on the
>> normative
>> aspects of RFC 4244.
>> 2. Added the use cases from target-uri the the summary
>> in the overview of rfc4244bis.
>> 3. Added an additional requirement to capture the "target-uri"
>> information.
>> 4. Fixed an error in the RFC 4244 ABNF and added "retarget"
>>
> parameter.
>
>> 5. Added a more simplified example.
>>
>>
>> We had some very long offline exchanges as to the best way
>> forward
>>
> and
>
>> remaining work for both documents.
>>
>> Some of the issues identified are:
>>
>> ::Issues::
>> 1. Should we remove the normative text from target-uri and
>>
> progress
>
>> 4244bis along with the target-uri document to meet the
>> chartered
>> SIP WG milestone?
>>
>>
>> 2. Name of the parameter.
>> At the last meeting, parameter "target" was said
>>
> inappropriate
>
>> because voicemail-uri spec already defines a parameter
>>
> called
>
>> "target" which also can be found in hi-entry, thus
>>
> potentially
>
>> causing confusion.
>>
>> Currently the target-uri draft uses "istarget" and 4244bis
>>
> uses
>
>> "retarget" but we could never come to
>> a consensus on what name is appropriate. Other suggestions
>>
> have
>
>> included the following:
>> "target-identity" (someone didn't like that "identity" is
>> also a SIP header)
>> "reg-uri" (can be paired with "mapped-uri" for item 3
>>
> below)
>
>> "aor"
>> "jibberish"
>> etc.
>>
>> One reason this is so difficult relates to the problem
>> statement in target-uri in that
>> RFC 3261 doesn't differentiate the mechanism by which the
>>
> new
>
>> (target) Request-URI is selected. Another issue is that
>> some of the terminology in
>> RFC 3261 is overloaded - e.g., "forwarding" refers both to
a
>> Proxy
>> which does not have responsibility for the domain of the
>> request-URI
>> in the incoming request, thus the proxy just "forwards" the
>> request to
>> the next hop AND "forwarding" is used to describe the
>> process whereby
>> the outgoing request is built and "forwarded" to the next
>> hop at which
>> point the proxy does not know how the new request-uri was
>> selected.
>> RFC 4244 has attempted to clarify the terms and attempts to
>> use "forward"
>> in the context of the former situation and "retarget" for
>> the case whereby
>> a proxy is responsible for the domain and thus can use a
>> number of
>> mechanism to select the new target for the request - e.g.,
a
>> REGISTRAR,
>> configured data, etc.
>>
>> 3. Related to the last point in item 2 above, it has been
>> proposed that
>> we differentiate the hi-entries even more by defining
>> separate parameters
>> for registered and configured/mapped contacts.
>> Currently when the R-URI is translated to a URI which is
>> either derived
>> from location service lookup(registered by UA) or from
>>
> mapping
>
>> table, there is no differentiation as to how the URI was
>> derived once it is
>> added to the list of potential targets.
>>
>> The general consensus of the authors of the two documents
was
>> that it may
>> be useful for some services to have the hi-entries tagged
>> with the
>> more specific information.
>>
>> And, of course, this gets us into another naming contest. In
>> the end, the naming
>> is not so important as long as the term isn't too overloaded
>> and it is defined
>> precisely in the document(s).
>>
>> We would appreciate WG feedback on these issues and any other
>> comments on
>> the two documents prior to IETF-74.
>>
>> Regards,
>> Shida and Mary.
>>
>>
>>
>> Begin forwarded message:
>>
>>> *From: *
Internet-Drafts at ietf.org
>>>
> <mailto:
Internet-Drafts at ietf.org>
>
>>> *Date: *March 10, 2009 2:30:01 AM JST
>>> *To: *
i-d-announce at ietf.org <mailto:
i-d-announce at ietf.org>
>>> *Subject: **I-D
>>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
>>> *Reply-To: *
internet-drafts at ietf.org
>>> <mailto:
internet-drafts at ietf.org>
>>>
>>> A New Internet-Draft is available from the on-line
>>>
> Internet-Drafts
>
>>> directories.
>>>
>>>
>>> Title
>>> : Delivery of Request-URI Targets to User Agents
>>> Author(s)
>>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S.
Schubert
>>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt
>>> Pages
>>> : 16
>>> Date
>>> : 2009-3-9
>>>
>>> When a Session Initiation Protocol (SIP) proxy receives a
request
>>> targeted at a URI identifying a user or resource it is
>>>
> responsible
>
>>> for, the proxy translates the URI to a registered or
configured
>>> contact URI of an agent representing that user or resource.
>>> In
>>>
> the
>
>>> process, the original URI is removed from the request.
>>> Numerous use
>>> cases have arisen which require this information to be
>>>
> delivered to
>
>>> the user agent. This document describes these use cases and
>>> defines
>>> an extension to the History-Info header field which allows it
>>>
> to be
>
>>> used to support those cases.
>>>
>>> A URL for this Internet-Draft is:
>>>
>>>
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d
>>> e
>>> livery-01.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>>
ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of
the
>>> Internet-Draft.
>>>
>> Content-Type: text/plain<BR>Content-ID:
>> &
lt;2009-3-9102756.I-D at ietf.org
>> <mailto:
2009-3-9102756.I-D at ietf.org>><BR><BR>
>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>>
I-D-Announce at ietf.org <mailto:
I-D-Announce at ietf.org>
>>>
https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories:
http://www.ietf.org/shadow.html
>>> or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>> _______________________________________________
>> Sip mailing list
https://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use
sip-implementors at cs.columbia.edu
>> <mailto:
sip-implementors at cs.columbia.edu> for questions on
>> current
>>
> sip
>
>> Use
sipping at ietf.org <mailto:
sipping at ietf.org> for new
>> developments on the application of sip
>>
>>
>>