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