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

"Elwell, John" <john.elwell@siemens.com> Wed, 19 October 2005 19:31 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJei-00031o-NO; Wed, 19 Oct 2005 15:31:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJeg-00031d-6p for sipping@megatron.ietf.org; Wed, 19 Oct 2005 15:31:18 -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 PAA08487 for <sipping@ietf.org>; Wed, 19 Oct 2005 15:31:08 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJqQ-00064c-9w for sipping@ietf.org; Wed, 19 Oct 2005 15:43:29 -0400
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IOM00C01GR89O@siemenscomms.co.uk> for sipping@ietf.org; Wed, 19 Oct 2005 20:28:20 +0100 (BST)
Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IOM0095UGR8WL@siemenscomms.co.uk>; Wed, 19 Oct 2005 20:28:20 +0100 (BST)
Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <TTA7HYRG>; Wed, 19 Oct 2005 20:30:49 +0100
Content-return: allowed
Date: Wed, 19 Oct 2005 20:30:47 +0100
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
To: Francois Audet <audet@nortel.com>, Dean Willis <dean.willis@softarmor.com>, Paul Kyzivat <pkyzivat@cisco.com>
Message-id: <50B1CBA96870A34799A506B2313F266706BD9795@ntht201e.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-type: text/plain
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: sipping <sipping@ietf.org>
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

Sorry for the delay, but my incoming email seemed to be delayed last night,
so I have a huge backlog this evening. See in-line.

> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com] 
> Sent: 18 October 2005 22:11
> To: Dean Willis; Paul Kyzivat
> Cc: sipping; Elwell, John
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> > 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.
> 
> That's what I was saying indeed. 
> 
> Let's wait for John to clarify what he meant...
[JRE] My expectations seem to differ somewhat from my co-author's, but I
think both are accommodated by the draft. I would like to be able to supply
service retargeting information to any UAS user or application I choose, in
order to advise them what happened to the call before it reached them,
rather than having to supply information to suit a particular application
that I am retargeting to. For example, suppose I forward my calls or some of
my calls on busy to a deputy (e.g., assistant, member of staff, colleague,
secretary, application). I just wish to say that this call was service
retargeted from me to him/her because of busy. That user or application can
do what it wants with that information. For example, a VM might use it to
get to the right mailbox and choose the right greeting. A simple telephone
might just display something appropriate in the local language.


> 
> > 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.
> 
> Yes.
> 
> > 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.
> 
> I think it's pretty obvious we failed on the "confusion" front...
> 
> Thanks.
> 

_______________________________________________
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