RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)

["DRAGE, Keith \(Keith\)" <[e-mail]>]

So out of interest which group would you slot the subdomain to domain
translation in, e.g.

[e-mail] to [e-mail] 

And vice versa.

And I agree, we do need some vocabulary in this area.

There was a definition of some terms at a higher level in 

http://tools.ietf.org/id/draft-rosenberg-rai-phone-names-numbers-00.txt

Which we may want to reuse as well.

Regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[e-mail]] 
> Sent: Thursday, January 17, 2008 7:13 PM
> To: IETF SIP List
> Subject: [Sip] Vocabulary and problem statement for 
> Request-URI, retargeting,and SIP routing (long, but read it!)
> 
> 
> The ongoing discussion around parameter passing mechanisms is 
> getting wrapped up in some concepts that we really haven't 
> yet described well enough to be communicating clearly. This 
> message is an attempt to develop a better understanding of 
> the basic problem.
> 
> Even given something as simple as a "SIP proxy", we have 
> three fundamentally different modes of operation, and one of 
> those modes has two sub-cases that require different thinking.
> 
> In the first fundamental mode, the destination of the request 
> is not changed by the proxy. The proxy gets the request, 
> looks at it, and makes a best guess as to where the request 
> should be sent so as to get the request closer to the 
> destination encoded in that request.  
> This is roughly analogous to IP routing, where the router 
> does not change any of the addresses encoded in the packet. I 
> call this fundamental mode "request routing".
> 
> In the second fundamental mode, the proxy alters the target 
> of the request. Under RFC 3261 as-is, this means that the 
> request-URI is changed by the action of the proxy. In 
> general, I call this fundamental mode "request retargeting", 
> except that our vocabulary isn't completely consistent here. 
> Incidentally, while the first fundamental mode is roughly 
> analogous to IP level routing, this second fundamental mode 
> is more similar to IP-level network address translation. Yes, 
> we've re-invented NAT. For the purpose of future clarity, I 
> propose we start calling this fundamental mode "request translation".
> 
> There are two sub-cases of the second fundamental mode -- 
> that is, two kinds of request translation.
> 
> In the first sub-case, the proxy transforms the request-URI 
> in a way that preserves the identity of the target. That is, 
> the request is still going to the same distinct entity, it's 
> just using a different request URI to get there. This is what 
> happens when a "home proxy"  
> does what I have in the past called "contact routing" and the 
> original request URI is transformed from an AOR into a 
> contact URI registered against that AOR. The important thing 
> here is that it is reasonable for the message sender to 
> expect the message recipient to be able to authenticate using 
> the identities expressed in the To:  
> header field, which is in general the same as the identity 
> expressed in the original Request URI -- that is, as the AOR. 
> So for example:  
> sip:[e-mail] registers from sip:Bob@192.168.1.1. Alice 
> calls sip:[e-mail]. Bob's proxy transforms this to 
> sip:Bob@192.168.1.1. Bob gets the request, extracts the To" 
> header field, and could reasonably insert an Identity header 
> into the response claiming to be "sip:[e-mail]".
> 
> As I said, I've previously called this first sub-case 
> "contact routing". We probably shouldn't, since properly it 
> is a translation (the request URI changes), not routing. I 
> suggest that we call this "translation with preservation of 
> target identity" until somebody comes up with a catchier 
> name. The most common example of translation with 
> preservation of identity is probably the "home proxy" 
> applying a Contact:, which we might call "contact 
> translation". Perhaps we could use "rerouting" as a short 
> name, and use "contact rerouting" for the thing that a home 
> proxy does.
> 
> In the second sub-case of the second fundamental mode, the 
> proxy transforms the request URI in a way that does NOT 
> preserve the identity of the target. That is, the request is 
> going to a distinctly different entity from that indicated by 
> the original request URI and the To: header field. Such a 
> case arises if Bob forwards his calls to Charlie. Alice sends 
> a request to "sip:[e-mail]" and gets back a response 
> can only be authenticated as being from 
> "sip:[e-mail]". It is this second case that gives 
> rise to the unanticipated response problem and has lead 
> people to propose that all retargeting be replaced with 
> redirection. We might call this sub-case "translation without 
> preservation of target identity". We've often called this 
> sub-case "retargeting" in the past.
> 
> We also have a third fundamental mode, "redirection". In this 
> mode, the proxy sends a response that encodes a new target 
> for subsequent requests. The identity of this new target is 
> independent from the identity of the original target -- it 
> may or may not be the same, and the act of redirection says 
> nothing about this relationship. As an example, Alice calls 
> sip:[e-mail]. The proxy at example.com sends Alice a 
> response redirecting her to "sip:[e-mail]".  
> Alice then calls "sip:[e-mail]".
> 
> 
> So to recap, we have three basic proxy operations in RFC 3261:
> 
> 1) Request routing, which preserves the request URI.
> 
> 2) Request rerouting, which changes the request URI but 
> preserves the identity of the request's target.
> 
> 3) Request retargeting, which changes the request URI and 
> changes the identity of the request's target.
> 
> We also have a related operation:
> 
> 4) Request redirection, which informs an upstream node about 
> a new identity to target instead of the original.
> 
> 
> As a further layer of complexity. note that these proxy 
> operations can be stacked. That is, we might, in the process 
> of dealing with one request, see multiple applications of the 
> first three, followed by an application of the fourth.
> 
> 
> Leaving the unanticipated response problem aside, we have two 
> fundamental problems with both rerouting and retargeting. The 
> various Called-Party-ID, Target, UA-Loose-Route,and other 
> such mechanisms are attempting to solve these problems. 
> History-Info provides a related set of solution that also 
> encompasses request redirection.
> 
> Problem 1: Expressing the identity that was originally the 
> target of the request.
> 
> Problem 2: Delivering any end-to-end parameters that might 
> have been encoded in the original request URI. Note that this 
> is complicated by the possibility of end-to-middle parameters 
> that need to be stripped by a mid-path node.
> 
> We also have a related problem that, AFAIK, neither CPID, nor 
> Target nor UA-Loose-Route attempt to solve, but that 
> History-Info does attempt, which is:
> 
> Problem 3: Expressing what operations have occurred, and WHY 
> they have occurred, in such a way that the target, mid-path 
> boxes, and/or the requester can do something useful with this 
> knowledge.
> 
> I've always held that this last problem is infinitely complex 
> and that we should not try to solve it in the general case, 
> which explains my reluctance to attack the History-Info 
> problem (or indeed the old Diversion header, which also 
> tickled part of this problem space). Building applications 
> that require Ultimate Understanding seems to me to be a Bad 
> Idea. Much as the invention of time travel will have made the 
> concept of future-perfect tense untenable (the future will 
> have been found not to have been perfect after all), so too 
> is the concept of Ultimate Understanding untenable -- if you 
> know everything, you can't possibly understand it since 
> understanding requires knowledge outside the subject being 
> considered, and if you understand everything you know, you'll 
> understand you don't know everything. And that sums up the 
> way I currently feel about the whole 
> US-Loose-Route/CPID/Target discussion.
> 
> Conclusion:
> 
> New proposed vocabulary for proxy operations: request 
> routing, rerouting, retargeting, and redirection.
> 
> Call for clarity on exactly which problems we're solving with 
> UA- Loose-Routing, target, CPID, etc. Proposed: target 
> identity, end-to- end parameters.
> 
> 
> --
> Dean Willis
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [e-mail] for questions on current sip 
> Use [e-mail] for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip