Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 16 January 2008 14:45 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 1JF9WX-0002qF-Ja; Wed, 16 Jan 2008 09:45:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF9WW-0002nX-2e for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:45:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9WV-0002ku-LX for sip@ietf.org; Wed, 16 Jan 2008 09:45:47 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9WU-000540-TO for sip@ietf.org; Wed, 16 Jan 2008 09:45:47 -0500
Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id B71FF7DFE; Wed, 16 Jan 2008 06:45:45 -0800 (PST)
Received: from [192.168.0.100] (pool-71-240-224-250.fred.east.verizon.net [71.240.224.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 7E43D7DF8; Wed, 16 Jan 2008 06:45:43 -0800 (PST)
Message-ID: <478E1897.8030905@joelhalpern.com>
Date: Wed, 16 Jan 2008 09:45:43 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF SIP List <sip@ietf.org>
Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.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><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A<CA9998CD 4A020D41 8654FCDEF4E7 07DF04173AE9@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF04173CB8@esealmw113.eemea.ericsson.se>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=SPF_NEUTRAL
X-Spam-Level: *
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: Francois Audet <audet@nortel.com>
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

Maybe I am missing something simple.
But, as I said at the meeting when Jonathan's draft was discussed, the 
main problem I have with the proposed solution(s) relates to the 
distinction between retargeting and routing.  This distinction seems to 
be central to both proposals.
The description of the distinction looks clear enough in the abstract.
But when I try to analyze how a proxy would actually know which 
operation it is performing, it is not clear.  Sometimes I am sure it 
will "just work."  But the description, and thinking about the wide 
range of actual things proxies do, leaves me very uncertain as to the 
clarity.

So I would at least like to ask if other folks find the distinction 
sufficiently clear to be reliable for meeting the need.  My own hope had 
been that this process would either clarify the distinction or provide a 
different distinction which was clearer.

Again, I may be off in left field, but after reviewing the drafts again 
I felt I had to ask.

Joel



_______________________________________________
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