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
