Re: [splices] SIP INVOKE method

["Shekh-Yusef, Rifaat (Rifaat)" <[e-mail]>]

Can you, or someone else, propose some text around this?

Regards,
 Rifaat

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Christer Holmberg
> Sent: Wednesday, May 18, 2011 1:35 PM
> To: Paul Kyzivat; Peter Musgrave
> Cc: [e-mail]
> Subject: Re: [splices] SIP INVOKE method
> 
> 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
> _______________________________________________
> splices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/splices