So out of interest which group would you slot the subdomain to domain translation in, e.g.
[EMAIL PROTECTED] to [EMAIL PROTECTED] 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] registers from sip:[EMAIL PROTECTED] Alice > calls sip:[EMAIL PROTECTED] Bob's proxy transforms this to > sip:[EMAIL PROTECTED] Bob gets the request, extracts the To" > header field, and could reasonably insert an Identity header > into the response claiming to be "sip:[EMAIL PROTECTED]". > > 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:[EMAIL PROTECTED]" and gets back a response > can only be authenticated as being from > "sip:[EMAIL PROTECTED]". 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:[EMAIL PROTECTED] The proxy at example.com sends Alice a > response redirecting her to "sip:[EMAIL PROTECTED]". > Alice then calls "sip:[EMAIL PROTECTED]". > > > 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 > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
