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

"Francois Audet" <audet@nortel.com> Fri, 21 October 2005 18:42 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1q4-0004Na-2n; Fri, 21 Oct 2005 14:42:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1q2-0004Mm-GT for sipping@megatron.ietf.org; Fri, 21 Oct 2005 14:41:58 -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 OAA24864 for <sipping@ietf.org>; Fri, 21 Oct 2005 14:41:47 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET22D-0001MM-LL for sipping@ietf.org; Fri, 21 Oct 2005 14:54:34 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9LId0l18715; Fri, 21 Oct 2005 14:39:00 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
Date: Fri, 21 Oct 2005 13:41:26 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF04DFE1EA@zrc2hxm0.corp.nortel.com>
Thread-Topic: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
Thread-Index: AcXUwAsx4pd7bTXMRQWN3yDl4rgVPABrtU9g
From: Francois Audet <audet@nortel.com>
To: Dean Willis <dean.willis@softarmor.com>, David R Oran <oran@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: quoted-printable
Cc: "Elwell, John" <john.elwell@siemens.com>, Paul Kyzivat <pkyzivat@cisco.com>, sipping <sipping@ietf.org>, "Michael Hammer (mhammer)" <mhammer@cisco.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

Yes, I beleive the approach Dave Oran is suggesting was presented like a
million
IETFs ago, and was nor received favorably because of what Dean is
describing.


> -----Original Message-----
> From: sipping-bounces@ietf.org 
> [mailto:sipping-bounces@ietf.org] On Behalf Of Dean Willis
> Sent: Wednesday, October 19, 2005 08:11
> To: David R Oran
> Cc: sipping; Audet, Francois [SC100:9T51:EXCH]; Elwell, John; 
> Paul Kyzivat; Michael Hammer (mhammer)
> Subject: Re: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 
> On Wed, 2005-10-19 at 09:22 -0400, David R Oran wrote:
> 
> > What we don't have a way of saying is "I'm busy, go try this other
> > place".
> . . .
> > A third way is to in fact invent a new 3xx which means exactly "Try
> > this other place because I'm busy" (as opposed to moved 
> temporarily).
> > 
> > Why don't we just do the last of these? It's completely
> > straightforward to me.
> 
> At first glance, it sounds fine. But then people are going to 
> want to say "I'm busy to you because you're on my warn list, 
> please try this other contact " and "I'm busy because my QoS 
> is saturated, please try this other destination" and "I'm 
> busy because I'm in a meeting, but I could do text messaging 
> too" and a million other things. We can't just add a new 
> response code for every one of these.
> 
> There are some fundamental problems with intertwingling 
> applications that use SIP with the SIP protocol itself, and I 
> think that the path you're suggesting leads to continuances 
> of this layer violation model.
> 
> Of course, we could just accept that the application-protocol 
> layer is completely violated in the SIP model, and just make 
> the best of what we have. I suppose that is an alternative.
> 
> --
> 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
> 
> 

_______________________________________________
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