Re: [splices] SIP INVOKE method

Paul Kyzivat <pkyzivat@cisco.com> Wed, 18 May 2011 17:29 UTC

Return-Path: <pkyzivat@cisco.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 C4BE4E06C2 for <splices@ietfa.amsl.com>; Wed, 18 May 2011 10:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level:
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 ML9SokNTP3nu for <splices@ietfa.amsl.com>; Wed, 18 May 2011 10:29:25 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BF737E06BE for <splices@ietf.org>; Wed, 18 May 2011 10:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6745; q=dns/txt; s=iport; t=1305739765; x=1306949365; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OfH9d36zBupzYtF/8dpUAJ+DvHpT9fjAuVEbCnwQcBI=; b=b9L4mdT2xPmQlCR+nlgG27uI789vvvwhgObJncK5S23Rga74V6a8LOCT i24V2GCtvqwNYdzXgDWJdtCjU+9CAWwXpy+7LzDwuElZvevzRIAZmSWee GUjP16e0O78/w5kIFv+BMEBbi5uCCvCH+Sxt05RhvnTNKPuEao4l5zNmQ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwAAMUA1E2rRDoJ/2dsb2JhbACXT45Nd4hwn3ueAIYZBJARhC+EHIZG
X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="359705677"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 18 May 2011 17:29:25 +0000
Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4IHTOZo016673; Wed, 18 May 2011 17:29:24 GMT
Message-ID: <4DD401F4.6050502@cisco.com>
Date: Wed, 18 May 2011 13:29:24 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Peter Musgrave <musgravepj@gmail.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> <BANLkTi=RrRrJEqrqVoWkS428y4-=TPZ16A@mail.gmail.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> <BANLkTikSBqp3bVHvX57Ekm07s+SDvcHGeA@mail.gmail.com>
In-Reply-To: <BANLkTikSBqp3bVHvX57Ekm07s+SDvcHGeA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 17:29:26 -0000

On 5/18/2011 11:43 AM, Peter Musgrave wrote:
> If INVOKE is to become a general method, then I could easily see people
> wanting to use e.g. an XML body to specify an action. If a new method is
> being defined then I would think making it fairly general would be a
> good idea - and limiting an action to one text line in a header  might
> be considered limiting. Hence a body would be more flexible.
>
> One the other hand being too general will likely get is into trouble
> again (e.g. the five uses of REFER) - so maybe being very specific is a
> good thing. In this case I could see just a header sufficing.
>
> A very classic dilemma...
>
> Do people feel that a general INVOKE mechanism is missing in SIP - or do
> we want to just focus on UA actions and the SPLICES requirement?

I think it needs to be general in the sense of not limited to the set of 
things decided at this time.

But not so general that it becomes a general purpose tunnel-over-sip 
mechanism. There needs to be a scope of applicability. I'm thinking its 
limited to controlling the behavior of a sip device with respect to the 
mapping of call streams to devices, initiating, terminating and 
otherwise managing calls, ...

AFAIK the main objection to bodies is the need to create a new parser. 
With a sip header you take advantage of the sip parser, though you may 
need to extend it to handle a new method. Some might object to XML 
bodies in particular because they require a fairly heavy parser, which 
can be a problem in limited devices. In some other devices of course 
that stuff is already present and so no burden.

Of course sip headers are just a special case of mime headers. Were we 
to choose as a body type another extension of mime, then it might still 
be possible to reuse a parser.

This clearly requires more discussion.

We might want to bring in a security guru sooner rather than later. I 
think there will likely be many concerns to be addressed, and addressing 
them may constrain the shape of the solution.

> Does this debate need to include sipcore?

You have me. :-)

It will certainly involve sipcore at some point.
I think we can explore the options for awhile before worrying too much 
about that. I'm more worried about security.

	Thanks,
	Paul

> Peter
>
>
>
> On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat)
> <rifatyu@avaya.com <mailto:rifatyu@avaya.com>> wrote:
>
>     Hi Peter,
>
>     Yes, I expect others to try to define new category of actions, but
>     these must be registered with IANA.
>
>     I am not clear on how this strengthens the case for using a body.
>
>     Regards,
>
>     Rifaat
>
>     *From:*Peter Musgrave [mailto:musgravepj@gmail.com
>     <mailto:musgravepj@gmail.com>]
>     *Sent:* Wednesday, May 18, 2011 9:32 AM
>
>
>     *To:* Shekh-Yusef, Rifaat (Rifaat)
>     *Cc:* Paul Kyzivat; splices@ietf.org <mailto:splices@ietf.org>
>
>     *Subject:* Re: [splices] SIP INVOKE method
>
>     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 <mailto: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
>     <mailto:pkyzivat@cisco.com>]
>      > Sent: Wednesday, May 18, 2011 8:58 AM
>      > To: Shekh-Yusef, Rifaat (Rifaat)
>
>      > Cc: splices@ietf.org <mailto: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> [mailto: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 <mailto: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 <mailto:splices@ietf.org>
>      > >> https://www.ietf.org/mailman/listinfo/splices
>      > >
>     _______________________________________________
>     splices mailing list
>     splices@ietf.org <mailto:splices@ietf.org>
>     https://www.ietf.org/mailman/listinfo/splices
>
>