Re: [splices] SIP INVOKE method

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
>
>