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 <[email protected]> wrote: > Responses below [MB]. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:[email protected]] > Sent: Wednesday, March 11, 2009 6:42 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 > > 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:[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-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: > >> <[email protected] <lt%[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
