Re: [splices] SIP INVOKE method

Peter Musgrave <musgravepj@gmail.com> Wed, 18 May 2011 15:43 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 2F0D4E06A0 for <splices@ietfa.amsl.com>; Wed, 18 May 2011 08:43:18 -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=[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 RyOxEH9Tr8ut for <splices@ietfa.amsl.com>; Wed, 18 May 2011 08:43:17 -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 8E4F3E067E for <splices@ietf.org>; Wed, 18 May 2011 08:43:16 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1494028fxm.31 for <splices@ietf.org>; Wed, 18 May 2011 08:43:15 -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=djNC+tGL9Cb/wnZVibuDdDhUoxRkiIh1sHMYTBmDEcw=; b=e2Re8SvPxFEa6CiIqCcKqnVlhwPt5GsU7Jm9tsaljluGm3TIbiKXAgrYnQn7oxbZEO GQ2cUDGo0Q51EyRL1h8H5ZZZtrJxPQ2qcu9GDB3Qj9osl8PSyCIpq4OYyWErznVSenNk +RLqBZvkrMqJk5PAXITC1mpbK191lmb2cjzpM=
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=ZoFDWRsaSj29vAoDIw/ZLB7vpXxlc4QvzLpzp6VY46Xf8uHlskOFVBoPG7jMeUo6NY JV/Fcbrs2zu/JofF8Xni+WpxMFjFRPJit79ZfQOJ7oKieT7zOmzMQa/WPqtNmRzWYuvs iC5hfm62ZRcbT16BvmRJxg62YqrsFXhTopIOM=
MIME-Version: 1.0
Received: by 10.223.117.137 with SMTP id r9mr2555416faq.28.1305733395368; Wed, 18 May 2011 08:43:15 -0700 (PDT)
Received: by 10.223.103.67 with HTTP; Wed, 18 May 2011 08:43:15 -0700 (PDT)
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@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> <BANLkTi=RrRrJEqrqVoWkS428y4-=TPZ16A@mail.gmail.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com>
Date: Wed, 18 May 2011 11:43:15 -0400
Message-ID: <BANLkTikSBqp3bVHvX57Ekm07s+SDvcHGeA@mail.gmail.com>
From: Peter Musgrave <musgravepj@gmail.com>
To: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
Content-Type: multipart/alternative; boundary=001636c5974c33cba204a38ebfaa
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 15:43:18 -0000

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? Does this
debate need to include sipcore?

Peter



On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) <
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]
> *Sent:* Wednesday, May 18, 2011 9:32 AM
>
> *To:* Shekh-Yusef, Rifaat (Rifaat)
> *Cc:* Paul Kyzivat; 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> 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
>
>
>