Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

Dean Willis <dean.willis@softarmor.com> Tue, 18 October 2005 20:20 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxwl-00051n-KV; Tue, 18 Oct 2005 16:20:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxwi-00050z-Qo for sipping@megatron.ietf.org; Tue, 18 Oct 2005 16:20:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04002 for <sipping@ietf.org>; Tue, 18 Oct 2005 16:20:21 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERy8I-0003oP-Sk for sipping@ietf.org; Tue, 18 Oct 2005 16:32:28 -0400
Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com [64.101.149.214] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9IKPOHK005067 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Oct 2005 15:25:27 -0500
In-Reply-To: <435531CA.9060407@cisco.com>
References: <1ECE0EB50388174790F9694F77522CCF04C4DC5C@zrc2hxm0.corp.nortel.com> <435531CA.9060407@cisco.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <176226B9-2751-4D1A-8FE2-03C49DA14F9C@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
Date: Tue, 18 Oct 2005 15:20:19 -0500
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: sipping <sipping@ietf.org>, Francois Audet <audet@nortel.com>, "Elwell, John" <john.elwell@siemens.com>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

On Oct 18, 2005, at 12:32 PM, Paul Kyzivat wrote:
>
> I would say that in the VM case the proxy knows the target is a VM  
> system, and in the other case the proxy knows *nothing* about the  
> characteristics of the target. It might be an application. It might  
> be a user device, or it might be an AOR that could route to either  
> a user device, a VM, some other application, or yet another unknown  
> target.
>

In which case, if we follow the principles of RFC 3087, it becomes  
the responsibility of whoever fills in this URI to include whatever  
parameters are needed by the target. I'm fairly happy with that  
understanding, if that's what Francois is really saying, and if John  
and the other folks agree.

So if that's true, what we're talking about here is really something  
like the netann draft, in that it is informationally defining some  
reusable parameters for specific services that are invoked in a  
manner consistent with RFC 3087. If that's what we want, I think  
that's a manageable scope and something we know how to do.

Like netann and 3087, this doesn't even have to be (although it could  
be, if we have that sort of consensus) a working group document. It  
could proceed as an individual informational. Of course, like netann,  
we'd still want to make sure it actually answers the questions and  
doesn't confuse people excessively.

--
Dean



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP