Re: [splices] SIP INVOKE method
Peter Musgrave <musgravepj@gmail.com> Wed, 18 May 2011 13:41 UTC
Return-Path: <musgravepj@gmail.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A7AE06FB for <splices@ietfa.amsl.com>; Wed, 18 May 2011 06:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e99QuyokY9mG for <splices@ietfa.amsl.com>; Wed, 18 May 2011 06:41:26 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0926E06C5 for <splices@ietf.org>; Wed, 18 May 2011 06:41:25 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1375773fxm.31 for <splices@ietf.org>; Wed, 18 May 2011 06:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3uuUUhJcfSpYHxsAc8jwLmdJDB5N1cfxwzZUVYHYpmw=; b=dFkdhE8HDVmnHJU9ctq0HalZQRH57Jqjr3Xs33NlEeNinU7wpkXOYyFPH4qWRdCcGx ywMm0g+bIkZDtN28nkcmUbuLMlmE0lj8yWgD4nd8DoyQNo9JI4hUyEbZ1R3lsopYe5da xqiB3npKg99C65hdCcYQeFq69Mhvrw9UPP6Wc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j9sM0CcK3EUxoDMlqA8nap7UB+IfwrllYOesGbxIRjM6KvMBK8020tPZMpisW9/rRq uUVDNP+1XO0m7egVIiIg2jcry3j0rDY9wTClPnIuKlSwB0iTaJ33Ur9ixN/NSR6RDhHx 8K6fEtHTVxWNC9DwgeDg2L0q8kmt9RJm6oTi8=
MIME-Version: 1.0
Received: by 10.223.117.137 with SMTP id r9mr2394378faq.28.1305725518790; Wed, 18 May 2011 06:31:58 -0700 (PDT)
Received: by 10.223.103.67 with HTTP; Wed, 18 May 2011 06:31:58 -0700 (PDT)
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com>
References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <BANLkTinLjrS3DocT=_MbnDrHdoTLs7RuhQ@mail.gmail.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com>
Date: Wed, 18 May 2011 09:31:58 -0400
Message-ID: <BANLkTi=RrRrJEqrqVoWkS428y4-=TPZ16A@mail.gmail.com>
From: Peter Musgrave <musgravepj@gmail.com>
To: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
Content-Type: multipart/alternative; boundary="001636c5974cb8bf7204a38ce96f"
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] SIP INVOKE method
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2011 13:41:27 -0000
Rifaat, I agree with Paul - a body may make sense. If we are going as far as defining a new SIP METHOD - does it make sense to have separate problem domains for the URNs? Do we think in the future others might want a different "package" of actions for some other purpose? If so, I think this strengthens the case for using a body. Peter On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Paul, > > I am not talking about any intermediary, but about application servers on > the call path in an enterprise. > Some application servers might be interested in a specific action to push > application to the phone. > I agree that strong security is required and we are asking the client to > only allow authorized users to invoke an action by challenging the > INVOKE-Issuer. > > Regards, > Rifaat > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize the > requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping into these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong hands > > this stuff can do great damage. I predict that there will be a lot of > > demand for very strong security considerations. Putting the action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but I'm > inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices >
- Re: [splices] SIP INVOKE method gao.yang2
- [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method - implicit regist… Christer Holmberg
- Re: [splices] SIP INVOKE method - implicit regist… Adam Roach
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Parthasarathi R (partr)
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Parthasarathi R (partr)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Parthasarathi R (partr)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Salvatore Loreto
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Christer Holmberg
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method R.Jesske
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Hutton, Andrew