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

"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> Thu, 17 January 2008 19:35 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaWT-0001TO-6f; Thu, 17 Jan 2008 14:35:33 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFaWQ-0001Rl-HQ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 14:35:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaWQ-0001RZ-78 for sip@ietf.org; Thu, 17 Jan 2008 14:35:30 -0500
Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFaWO-0004DG-4q for sip@ietf.org; Thu, 17 Jan 2008 14:35:30 -0500
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m0HJZRcE012915; Thu, 17 Jan 2008 13:35:27 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 13:35:27 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 20:35:24 +0100
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)
Date: Thu, 17 Jan 2008 20:35:23 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001B490C0@DEEXC1U01.de.lucent.com>
In-Reply-To: <C8D63C78-437F-430E-950C-2E63C69E3CEF@softarmor.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)
Thread-index: AchZPVWoi0mzshahRDuimd0AEiSUwgAAlKKQ
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><CA9998CD4A020D418654FCDEF4E707DF040266B1@esealmw113.eemea.ericsson.se><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com><CA9998CD4A020D418654FCDEF4E707DF04051C9D@esealmw113.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><CA9998CD4A020D418654FCDEF4E707DF040960B7@esealmw113.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com>A<CA9998CD4A020D418654FCDEF4E707DF040D69C7@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><CA9998CD4A020D418654FCDEF4E707DF0413D587@esealmw113.eemea.ericsson.se><"0D5F89FAC29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen!s .net> A <CA99! 98CD4A020 D418654FCDEF 4E707DF04173CB8@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net>A<CA9998CD4A020D418654FCDEF4E707DF041743D6@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net><CA9998CD4A020D418654FCDEF4E707DF041C939B@esealmw113.eemea.ericsson.se> <C8D63C78-437F-430E-950C-2E63C69E3CEF@softarmor.com>
From: "DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 17 Jan 2008 19:35:24.0765 (UTC) FILETIME=[1B1BE0D0:01C85940]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

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

drage@swindon.alcatel-lucent.com to drage@alcatel-lucent.com 

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:dean.willis@softarmor.com] 
> 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:Bob@example.com registers from sip:Bob@192.168.1.1. Alice 
> calls sip:Bob@example.com. 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:Bob@example.com".
> 
> 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:Bob@example.com" and gets back a response 
> can only be authenticated as being from 
> "sip:Charlie@example.com". 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:Bob@example.com. The proxy at example.com sends Alice a 
> response redirecting her to "sip:carol@example.com".  
> Alice then calls "sip:carol@example.com".
> 
> 
> 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 
> sip-implementors@cs.columbia.edu for questions on current sip 
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip