Return-Path: 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 660DBE0703 for ; Wed, 18 May 2011 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 n4Hn4RZwQyO9 for ; Wed, 18 May 2011 09:26:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A3024E0665 for ; Wed, 18 May 2011 09:26:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f8-4dd3f3466b7d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C6.62.09774.643F3DD4; Wed, 18 May 2011 18:26:46 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 18 May 2011 18:26:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E82442441 for ; Wed, 18 May 2011 19:26:45 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D55D250F2D for ; Wed, 18 May 2011 19:26:45 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 88F6850F2C for ; Wed, 18 May 2011 19:26:45 +0300 (EEST) Message-ID: <4DD3F344.4050208@ericsson.com> Date: Wed, 18 May 2011 19:26:44 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.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> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090500080302090808090406" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 16:26:49 -0000 --------------090500080302090808090406 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I tend to agree that putting the action in the body seems to make more sense; even if I have to admit I haven't had time to think more about the issue. /Sal On 5/18/11 6:43 PM, 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? > Does this debate need to include sipcore? > > Peter > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > 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) > > 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 > > -- Salvatore Loreto www.sloreto.com --------------090500080302090808090406 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I tend to agree that
putting the action in the body seems to make more sense;
even if I have to admit I haven't had time to think more about the issue.


/Sal
 



On 5/18/11 6:43 PM, 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? 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

 




-- 
Salvatore Loreto
www.sloreto.com
--------------090500080302090808090406--