Re: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

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: 
> > &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
> 
_______________________________________________
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