Subject: Multiple Protocol Bindings (was RE: [XCON] Chair´s opinion :)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 7 Feb 2006 21:58:23 -0500

I will bite on the multiple protocol binding offer.

If we can say with a straight face that the two, application-level bindings of SOAP and CSCP are the same, we are saying that CSCP does everything that SOAP does, including all of the support infrastructure that SOAP brings.  I seriously doubt that, and we are thus going to be missing a bunch of functionality that you might not think is important, but will be incredibly useful when it comes to creating the interesting applications.

Let us say that we really, really don't need the "baggage" of SOAP.  Then I would offer that if the handset manufacturers are adamant about counting bits, and they get paid for having lots of stacks on the phone (hey - it is a new feature!), then you will not see any SOAP bindings.  Why?  If you have 300,000 handsets all talking CSCP, the application server vendors MUST do CSCP (or die).  Then, one has to ask why one would build a SOAP binding?  Oh yes - because the APPLICATIONS will come from the web services side of the house.  However, since it would be hard to find interoperable implementations for PS, the "secondary" transport gets dropped.

Of course, we then find SOAP conference control bindings in OASYS or (gasp) IMTC... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Wednesday, February 01, 2006 6:16 PM
To: Oscar Novo (JO/LMF)
Cc: Chris Boulton; [email-masked]; [email-masked]
Subject: Re: [XCON] Chair´s opinion :)

(as chair)

I am encouraged by the level and direction of this discussion - lets 
keep it up, everyone.

Having multiple transports is possible, of course.  Interop should be 
possible by requiring servers to support both transports while clients 
can support either.

However, I still think we need to decide the fundamental question of 
whether conference control is about data manipulation alone, data 
manipulation plus commands, or purely command based.  I would like to 
see this addressed.  The working group consensus on this will validate 
whether multiple transports or bindings will even work.

Thanks,
Alan Johnston
co-chair

Oscar Novo (JO/LMF) wrote:

>Yes, I think is good idea to know the chair's opinion in this discussion It would be useful for everybody. :)
>
>Oscar
>
>-----Original Message-----
>From: Chris Boulton [mailto:[email-masked]] 
>Sent: 30. tammikuuta 2006 13:17
>To: [email-masked]; Sean Olson; Henning Schulzrinne; Oscar Novo (JO/LMF)
>Cc: [email-masked]
>Subject: RE: [XCON] Conference Control
>
>So it looks to me like we MIGHT be getting somewhere.  I'd be interested to know what the chair's make of this current discussion and if they think it will be achievable.
>
>Chris.
>
>
>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]]
>Sent: 27 January 2006 23:29
>To: 'Sean Olson'; Chris Boulton; 'Henning Schulzrinne'; 'Oscar Novo (JO/LMF)'
>Cc: [email-masked]
>Subject: RE: [XCON] Conference Control
>
>Just to be clear, I don't have a problem with multiple bindings as long as the underlying data structures and operations are the same.
>
>I think having a protocol that had both a SOAP binding, and something fast and small, especially for the typical operations, is a good thing.
>
>Brian
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Olson
>Sent: Friday, January 27, 2006 6:26 PM
>To: Chris Boulton; Henning Schulzrinne; Oscar Novo (JO/LMF)
>Cc: [email-masked]
>Subject: RE: [XCON] Conference Control
>
>I think Chris' proposal is very reasonable. Why is this an either-or discussion? Why not allow multiple bindings? I think it would be a mistake to create a least common denominator approach to satisfy the constraints of CPU/bandwidth limited devices.  
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
>Sent: Friday, January 27, 2006 9:28 AM
>To: Henning Schulzrinne; Oscar Novo (JO/LMF)
>Cc: [email-masked]
>Subject: RE: [XCON] Conference Control
>
>
>
>Compared to implementing the logic of conference control, the encapsulation is a tiny fraction of the work, particularly given that you can get SOAP stacks pre-packaged for almost any conceivable platform and language, mobile or otherwise. (A SOAP client is nothing more than a bit of XML on top of HTTP, so you don't even need a stack, just an XML parser and an HTTP client library, both of which any SIP-speaking device will need in any event.)
>
>[Chris Boulton] Agreed.
>
>Thus, I don't think this is much of a differentiator.
>
>[Chris Boulton] Either way - I am fed up of it being 'the only'
>differentiator.
>
>Oscar Novo (JO/LMF) wrote:
>  
>
>>I think it´s quite obvious. :)
>>But anyway, still all the systems have to implement the SOAP protocol 
>>from the scratch and this is not the case of CSCP even if the systems 
>>that support the BFCP are low.
>>    
>>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/xcon
>
>
>Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.
>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/xcon
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/xcon
>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/xcon
>
>
>  
>

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon