Subject: RE: [XCON] Conference Control

From: "Chris Boulton" <[email-masked]>
Date: Fri, 27 Jan 2006 15:59:32 -0000

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. 

Don´t be mad at me. :)

[Chris Boulton] hehehe - how could I.  This isn't a 'vs' debate - I'm just saying that if you have got a web services SOAP interface, it would be useful for XCON to provide hooks so that clients (e.g. J2EE applications not UA's or handsets) can control conferences using mechanisms that they find common e.g. SOAP, WSDL, UDDI.  I agree that this Conference System would almost certainly have a BFCP interface (and therefore a CSCP interface), but my client application would probably not. 

  _____  

From: Chris Boulton [mailto:[email-masked]] 
Sent: 27. tammikuuta 2006 17:43
To: Oscar Novo (JO/LMF); [email-masked]; [email-masked]
Cc: [email-masked]; Adam Roach
Subject: RE: [XCON] Conference Control

Chris,

Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this comments based on?

 So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch.

Oscar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 27. tammikuuta 2006 17:13
To: [email-masked]; [email-masked]
Cc: [email-masked]; Adam Roach
Subject: RE: [XCON] Conference Control

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 14:27
To: Chris Boulton; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces.  That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different.  I'm not sure that would be particularly interesting to you.

Also, could you clarify your statements on CSCP?  What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden".  I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden.  I think if you implement BFCP then CSCP is relatively less work from there. 

[Chris Boulton] The XCON Framework reads:

Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users.

So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory.  So for an element wanting to use just CSCP would have to develop from scratch.  In this scenario, just having to expose a WSDL initiated web interface is preferred.

Chris.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: Friday, January 27, 2006 5:01 AM
To: [email-masked]
Cc: [email-masked]; Adam Roach
Subject: [XCON] Conference Control

Hi All,

Just wanted to generate some discussion relating to the recent Conference Control submissions.  I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.  

While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion.  I have reviewed all of the proposals and will be providing questions and feedback in individual mails.  This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important.  As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on.  This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?'  As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice.  From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing.  As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset.  I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures.

I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months.

Best Regards,

Chris Boulton.

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 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jan 2006 11:01:57 -0500

Okay, so, we could talk about two bindings for one data model/interaction
model if we wanted to.  

An interesting question follows from that: would you want a SOAP based
binding for floor control?

Brian

  _____  

Sent: Friday, January 27, 2006 11:00 AM

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. 

Don´t be mad at me. :)

[Chris Boulton] hehehe – how could I.  This isn’t a ‘vs’ debate – I’m just
saying that if you have got a web services SOAP interface, it would be
useful for XCON to provide hooks so that clients (e.g. J2EE applications not
UA’s or handsets) can control conferences using mechanisms that they find
common e.g. SOAP, WSDL, UDDI.  I agree that this Conference System would
almost certainly have a BFCP interface (and therefore a CSCP interface), but
my client application would probably not. 

  _____  

 

Chris,

Notice that almost all the conference systems will implement the BFCP even
thought it is not compulsory.

 So, at the end few systems would have to develop the protocol from scratch
but If SOAP is going to be the protocol all the conference systems have to
develop the protocol from scratch.

Oscar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 14:27
To: Chris Boulton; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

I’m not opposed to having two bindings to the same interface, but I would
not want to see two interfaces.  That means the models, data structures,
operations, errors, etc would have to be identical, with only transport
being different.  I’m not sure that would be particularly interesting to
you.

Also, could you clarify your statements on CSCP?  What you said was “it may
be likely, as it is not mandatory, that BFCP be implemented in the solution
and so developing support for something like CSCP would be seen as a
burden”.  I can’t figure out if you WILL implement BFCP, and thus CSCP is
easy, or you won’t implement BFCP because it’s not mandatory and thus CSCP
would be a burden.  I think if you implement BFCP then CSCP is relatively
less work from there. 

Floor control is not a mandatory mechanism for a conferencing system
implementation but provides advanced media input control features for
conference users.

So the point I was trying to convey was that BFCP, as it stands in the
Framework is not mandatory.  So for an element wanting to use just CSCP
would have to develop from scratch.  In this scenario, just having to expose
a WSDL initiated web interface is preferred.

Chris.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: Friday, January 27, 2006 5:01 AM
To: [email-masked]
Cc: [email-masked]; Adam Roach
Subject: [XCON] Conference Control

Hi All,

Just wanted to generate some discussion relating to the recent Conference
Control submissions.  I would like to begin by thanking all the relevant
parties for the effort contributed before Christmas.  

While I realise that the thoughts conveyed in this mail are a little
controversial, I thought I would poke my head up into the firing line in
attempt to stimulate some discussion.  I have reviewed all of the proposals
and will be providing questions and feedback in individual mails.  This mail
is an attempt to discuss some architectural decisions that I personally feel
are equally as important.  As some of you may already know, I am a supporter
of the SOAP proposals (Henning, myself and Mary) that are currently being
worked on.  This led me to realise that my preference was being swayed
(purely selfish :-) by ‘who exactly will be a conference client manipulating
Conference Objects?’  As an application server vendor who’s product very
much utilises web services. SOAP seems the obvious choice.  From a handset
vendor I can also see that proposals such as CCCP and CSCP are more
appealing.  As an application server offering conferencing services using
web services it may be likely, as it is not mandatory, that BFCP be
implemented in the solution and so developing support for something like
CSCP would be seen as a burden, especially as we already have a web services
interface that provides all the relevant infrastructure to link to our
clients.

It is for these reasons that I was pondering the prospect of XCON allowing
both a handset friendly interface such as CSCP and a SOAP interface for web
services where the client might well be another application and not a
handset.  I realise that having two interfaces is not ideal, but as long as
we are careful in our rules on minimal implementation and ability to
advertise capabilities to a Conference Client I personally feel that this is
the best solution to make XCON appealing to a wide variety of architectures.

I’m going to duck now and wait for incoming bullets but on a serious note I
strongly appeal to all who are interested on making Dallas a productive
meeting to comment on mails such as this over the coming months.

Best Regards,

Chris Boulton.

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