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.
What has been lost is the current target of the request:
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.
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:[email protected]]
Sent: Wednesday, March 11, 2009 4:40 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Shida Schubert; [email protected]
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:[email protected]]
*Sent:* Wednesday, March 11, 2009 3:59 AM
*To:* Shida Schubert
*Cc:* [email protected] 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 <[email protected]
<mailto:[email protected]>> 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: *[email protected]
<mailto:[email protected]>
*Date: *March 10, 2009 2:30:01 AM JST
*To: *[email protected] <mailto:[email protected]>
*Subject: **I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
*Reply-To: *[email protected]
<mailto:[email protected]>
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-de
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:
<[email protected]
<mailto:[email protected]>><BR><BR>
_______________________________________________
I-D-Announce mailing list
[email protected] <mailto:[email protected]>
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 [email protected]
<mailto:[email protected]> for questions on current
sip
Use [email protected] <mailto:[email protected]> for new
developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
