Re: [splices] SIP INVOKE method

[Christer Holmberg <[e-mail]>]

Hi,

I have a similar comment, regarding the applicability.

The draft says that each "action" must be represented by a URN that is defined by IANA.
 
But, there are no restrictions regarding what types of "actions" are allowed - or even a description about what the criterias for an "action" are in the first place. 
  
Regards,

Christer

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Paul Kyzivat [[e-mail]]
Sent: Wednesday, May 18, 2011 8:29 PM
To: Peter Musgrave
Cc: [e-mail]
Subject: 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)
> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Wednesday, May 18, 2011 9:32 AM
>
>
>     *To:* Shekh-Yusef, Rifaat (Rifaat)
>     *Cc:* Paul Kyzivat; [e-mail] <mailto:[e-mail]>
>
>     *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)
>     <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>]
>      > Sent: Wednesday, May 18, 2011 8:58 AM
>      > To: Shekh-Yusef, Rifaat (Rifaat)
>
>      > Cc: [e-mail] <mailto:[e-mail]>
>      > 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: [e-mail]
>     <mailto:[e-mail]> [mailto:[e-mail]
>     <mailto:[e-mail]>] On Behalf
>      > Of
>      > >> Paul Kyzivat
>      > >> Sent: Tuesday, May 17, 2011 3:09 PM
>      > >> To: [e-mail] <mailto:[e-mail]>
>      > >> 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
>      > >> [e-mail] <mailto:[e-mail]>
>      > >> https://www.ietf.org/mailman/listinfo/splices
>      > >
>     _______________________________________________
>     splices mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/splices
>
>
_______________________________________________
splices mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/splices