Subject: RE: [XCON] Conference Control

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

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 10:50:11 -0500

I guess that this is whether floor control is seen as a "must have" feature
in a conference client.

Basically, I think that if you need any more than the basic conference
control that comes with nothing more than the conference package and other
SIP mechanisms; that is, you implement the conference control package, you
have a rich enough client that floor control would be essential.  I'd be
hard pressed to think of a client that would have the conference control
package without floor control.  It's POSSIBLE, but I don't think its
probable.  Floor control is kind of a fundamental thing beyond the
simplistic kinds of conferences that don't need any of the xcon stuff.

Brian

  _____  

From: Chris Boulton [mailto:[email-masked]] 
Sent: Friday, January 27, 2006 10:42 AM
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.

 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

  _____  

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. 

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

  _____  

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

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 27 Jan 2006 15:21:28 -0800

I have to disagree .... you can have extremely feature rich conferencing
clients without a floor control protocol.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, January 27, 2006 7:50 AM
To: 'Chris Boulton'; 'Oscar Novo (JO/LMF)'; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

I guess that this is whether floor control is seen as a "must have"
feature in a conference client.

Basically, I think that if you need any more than the basic conference
control that comes with nothing more than the conference package and
other SIP mechanisms; that is, you implement the conference control
package, you have a rich enough client that floor control would be
essential.  I'd be hard pressed to think of a client that would have the
conference control package without floor control.  It's POSSIBLE, but I
don't think its probable.  Floor control is kind of a fundamental thing
beyond the simplistic kinds of conferences that don't need any of the
xcon stuff.

Brian

________________________________

 

Chris,

Oscar

________________________________

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

Chris.

Brian

________________________________

Hi All,

Best Regards,

Chris Boulton.