Yeah, we can define a new header and just ignore the use of a basic SIP building block that the WG spent 2.5 years (note this doesn't include the 2+ years spent on the doc as an individual and as a SIPPING WG document ;) And, while we're at it, let's just go ahead and obsolete 4244 altogether and standardize diversion (something the WG rejected almost a decade ago). That will make one vendor and a handful of SPs very happy and those of us that have implemented the specs can ripout some code after while when we have some spare change to pay folks to do so (and of course, this is after the folks that have not implemented diversion actually implement it - there are actually some of those out there).
As an aside, this is another fine example as to why we don't seem to make great progress or produce specs that are deemed useful - we agree on a way forward and then change our minds later (sometimes for good reasons and sometimes because a shortcut seems easier or it's just arbitrary based on the phase of the moon it seems). Mary. -----Original Message----- From: Hadriel Kaplan [mailto:[email protected]] Sent: Wednesday, March 11, 2009 1:55 AM To: Shida Schubert; [email protected] List Cc: Barnes, Mary (RICH2:AR00) 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
