Yes, because you are using
the 3261 use of target and the
4244bis introduced definition of retarget.
I thought it was clear that
we need other words as those definitions
don't match the target-uri
drafts use of the terms. Also they do not
suffice to provide a solution
for the use cases in the target-uri
draft.
The 3261 text you refer to is
exactly about the case where the
home proxy overwrites the Request-URI
with a new target. This target is
teh registered contact address. And
hence this would be what target-uri
calls a hop or a route. This case and
this is where it gets confusing is
not a "retarget" in the target-uri
draft use of the term.
The target-uri
draft states:
"To avoid confusion,
we
refer to a SIP URI that is an
address for a user or resource
as a
"target" and a SIP URI that is a hop for reaching that user
as
a
"hop".
Apparently that does not suffice to avoid
confusion.
As for the tagging, speaking
about the solution before agreeing
on the terminology and the problem it
should solve is meaningless.
/Hans Erik
van Elburg
On Thu, Mar 12, 2009 at
2:33 AM, Mary Barnes
<
mary.barnes at nortel.com>
wrote:
Responses below [MB].
-----Original Message-----
From: Hans Erik van Elburg
[mailto:
ietf.hanserik at gmail.com]
Sent: Wednesday, March 11,
2009 6:42 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
I was talking about the
concept.
The
use cases only describe cases where the target-uri
(lets call
that
current
target from now) has been lost when an initial
request for a
dialog or standalone request
arrives at the UAS.
[MB] And I think this is where the terminology confusion
starts -
I
don't think of
the "lost" target-uri as being the
"current" target. In
my mind, the "current" target is
reflected by the last
hi-entry and the
request-uri in the incoming request at the UAS.
If the
entity that sent
the request was the entity that added the last
hi-entry,
then the uri in
that hi-entry is the same as the request-URI in the
SIP
request that
arrives at the UAS. I refer to the "lost" uri as the one
that
was
"retargeted" -
that's the one the UAS wants to pull from
the hi-entries
in the incoming request. That
hi-entry was not the one
that was just
added by the entity that built the request just
received
by the UAS.
That hi-entry is tagged with whatever name we are going
to tag it
with
BEFORE the
request is forwarded (using the term forward
per section 16.6
of RFC 3261). That tag
is added once the target set of
potential
candidates for the new request uri are determined
in
section 16.5 of
3261 (with "target set" being a 3261 term), just before
the request
is
forwarded in
section 16.6 to one of those targets. A
new hi-entry
(which will be the last
hi-entry in the request received
by the UAS) is
added in section 16.6 of 3261 as the
request is
forwarded. At this
point in time, the lost information is in the
previous
hi-entry when the
outgoing request is sent. [/MB]
What has been lost is the current target
of the request:
[MB] Right - at which point in my mind, it's no longer
the
current
target ;)
Maybe we call it "lost". [/MB]
Current target
The current target of
an initial request for a dialog
or standalone
request is the name or address to
which the request is
targeted, i.e.
either the initial target inserted in the
Request-URI
by the UAC that
originates the request, or when a retarget
occurred,
the target
provided in that retarget operation. Reroute
and
translation
operations never change the current target.
[MB] I don't think this
definition fits what you want -
i.e., if there
is no retargeting, then none of the
hi-entries are
tagged - i.e., you
won't have your concept of current. The way it works
is
that if no
hi-entries are tagged, then you know that there was no
retargeting,
thus
you know the
request-uri has not been lost. [/MB]
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