Re: Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
"Christer Holmberg" <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <CA9998CD4A020D418654FCDEF4E707DF0BA7B192@esealmw113.eemea.ericsson.se> |
Hi, IF we would remove that requierment, and ONLY care about the case when the R-URI is replaced with the CONTACT, I don't think we need to do anything. I believe P-Called-Party-ID already solves that. Regards, Christer ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Elwell, John Sent: 12. maaliskuuta 2009 15:31 To: Hans Erik van Elburg Cc: [email protected] Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Hans Erik, The way I interpreted the 01 draft, you would not get the freephone number anyway. If that is a requirement, then I accept my suggestion won't suffice. John ________________________________ From: Hans Erik van Elburg [mailto:[email protected]] Sent: 12 March 2009 12:57 To: Elwell, John Cc: [email protected] Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B. A calls Bfreephonenumber routed the B (AOR) routed to B's contact. The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B. So what we like to see that B UA receives is something like H-I: Bfreephone; "istarget",\ B,\ contact-B So you want to get Bfreephonenumber and not B. In certain situations you are also interested in B, I guess that PBX's would interested in that to deliver to the correct user. We could distinguish them like: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B BR, /Hans Erik van Elburg On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John <[email protected]> wrote: If 'istarget' is used only to identify the value that was overwritten in the Request-URI by a contact URI, an alternative approach would be to flag the contact URI H-I entry as 'iscontact'. Then the UAS would just need to look for the most recent H-I entry that is not marked 'iscontact'. John ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 08:35 To: Mary Barnes Cc: [email protected] Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 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] <mailto:lt%[email protected]> <mailto:lt%[email protected] <mailto: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