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