Subject: [XCON] Chair´s opinion :)

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Wed, 1 Feb 2006 08:54:49 +0100

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 01 Feb 2006 15:15:35 -0800

(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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 01 Feb 2006 20:53:35 -0800

> whether multiple transports or bindings will even work.

I think this terminology heavily bias the decision but continuing on with it
...

Given how we have data in the server that is defined after the client is
compiled, I think there *has* to be some of what you call data manipulation
(though there could be toher things too). If someone disagrees with this,
then I am probably misunderstanding the terms.

I also think that with any command, you may have situations where you have
to set data at the same point. And I don't want two phase commits because
they are two hard to implement so the data needs to "go along" with the
command. 

If you accept we have to have the above, I rather have a small command set
than a large one because I think a small set will do.