Re: 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: 
> &lt;[email protected]&gt;<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