Sorry Keith ... I forgot to snip and transform to text. ________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Thursday, March 12, 2009 1:10 PM To: Hans Erik van Elburg; [email protected] Subject: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I think there is another solution proposal that we should pursue for issue 3 identified in the email summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the summary below. I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps this is why the other discussion threads aren't progressing well. So, Hans Erick, I would like clarification on as to your view on the solution: In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the solution to be that the hi-entries are tagged as they are added to the request. And, just for clarification from my perspective, that is NOT the solution in either 4244bis or target-uri. I don't view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear that's what you're advocating. In that case, I would agree the "retarget" is not an appropriate tag for the entries, as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would contain the same as the Request-URI in the incoming request), since it would be tagged if you use this solution approach. Thus, you'd have to take the next hi-entry that you find that has the desired "tag". I will posit that we could accomplish this solution without any changes to 4244 by just registering new SIP URI parameter(s). And, that's not to say we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri to describe a solution that makes use of 4244bis "as is". So, feedback on this specific point (from Hans Erik and others) would be appreciated. Mary. ________________________________ From: Shida Schubert [mailto:[email protected]] Sent: Wednesday, March 11, 2009 1:13 AM To: [email protected] List Cc: Barnes, Mary (RICH2:AR00) Subject: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt We have submitted the updated target-uri draft based on the comments submitted to the list and comments received at IETF73. ....snipped... 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-deliv ery-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
