Hi, We had a looooong discussion about that (ua-loose-route vs Target), and I really hope we should not go back there now.
I think we should focus on whether we want to have this in H-I, as currently proposed, or as a separate header. Regards, Christer > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Elwell, John > Sent: 11. maaliskuuta 2009 13:32 > To: Hadriel Kaplan; Shida Schubert; [email protected] > Cc: Mary Barnes > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > Just to expand on what Hadriel says, the SIP Forum is > addressing the case where a request is delivered by a SIP > Service Provider to a SIP-PBX, the SIP-PBX having registered > with the SIP-SP. The SIP-PBX needs to be in possession of the > target, in order to route onwards correctly within the > enterprise. If only the SIP-PBX's contact URI is available in > the Request-URI, the SIP-PBX would have to look elsewhere for > the target. In accordance with recent SIP WG agreements, this > would be the History-Info header field, but that requires the > present extension. > > Advantages of putting the target in the Request-URI for this > particular situation: > - This is where the SIP-PBX would normally expect to find the > target when a request is received from elsewhere (e.g., > another SIP-PBX within the enterprise), so it is reasonable > also to expect it there when received from a SIP SP. > - SIPConnect 1.1 will not require History-Info for any other > purpose, so it would make it a mandatory specification for > SIPConnect 1.1 just in order to solve this particular > problem, thereby raising the bar for SPs and SIP-PBXs wanting > to comply with the spec. > - We would need to define procedures for what to do if > History-Info is absent from a received request or if there is > no entry marked as 'istarget'. > - SIPConnect 1.1 is due for completion in the next few weeks, > and cannot wait the usual IETF cycle time for History-Info > update to hit the RFC Editor's queue. > - If History-Info is used anyway (for its original purpose), > the history revealed when a request comes from a SIP-SP via a > SIP-PBX to another proxy and finally to a UAS would be > unnecessarily complicated and therefore confusing, because > the target would be replaced by a contact and would then > appear again at the next hop. > > John > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf Of > > Hadriel Kaplan > > Sent: 11 March 2009 06:55 > > To: Shida Schubert; [email protected] List > > Cc: Mary Barnes > > Subject: Re: [Sip] Fwd: I-D > > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > At the risk of opening up a topic we have already agreed on, but in > > the spirit of open communication... [how's that for an opener!?] > > > > Are we absolutely sure we want to put this target-URI in the > > History-Info header? > > > > I am not asking this because I think it's hard. I am > asking because I > > am not sure it will be used. Several of us from this same WG are > > involved in the SIP-Forum's SIP-Connect profile, and when > faced with > > either using this new History-Info mechanism for a > target-uri delivery > > issue, vs. > > not, we chose not to. And we were mostly the same people who liked > > the idea of putting it in History-Info in the IETF! > > (myself included) But I am concerned that when given a reasonable > > opportunity to use a mechanism we ourselves promote when wearing a > > different hat, we chose not to use it in practice. It doesn't bode > > well. :( > > > > -hadriel > > p.s. sorry Mary for raising this, but there isn't much > email traffic > > anyway. :) > > > > ________________________________________ > > From: [email protected] [mailto:[email protected]] On > Behalf Of > > Shida Schubert > > Sent: Wednesday, March 11, 2009 2:13 AM > > To: [email protected] List > > > > 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] > > Date: March 10, 2009 2:30:01 AM JST > > To: [email protected] > > Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > Reply-To: [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-delivery-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]><BR><BR> > > _______________________________________________ > > I-D-Announce mailing list > > [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] for questions on current sip Use > > [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 > _______________________________________________ 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
