Subject: RE: [XCON] Chair´s opinion :)

From: "Chris Boulton" <[email-masked]>
Date: Thu, 2 Feb 2006 12:02:53 -0000

> 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.

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.

[Chris Boulton] Agreed.

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. 

[Chris Boulton] Agreed.

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.

[Chris Boulton] Again, Agreed.  Command set certainly doesn't need to be large. 

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: "Sean Olson" <[email-masked]>
Date: Thu, 2 Feb 2006 10:19:55 -0800

Yeah, not sure I understand the terminology either ... What is the purpose of the command if it does not involve some amount of data manipulation? The command set doesn't need to be large, but hopefully it is not just 4 commands (get, set, create, delete) ;-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: Thursday, February 02, 2006 4:03 AM
To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF)
Cc: [email-masked]; XCON-IETF
Subject: RE: [XCON] Chair´s opinion :)

> 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.

[Chris Boulton] Agreed.

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. 

[Chris Boulton] Agreed.

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.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 02 Feb 2006 11:48:19 -0800

(not as chair)

>Yeah, not sure I understand the terminology either ... What is the purpose of the command if it does not involve some amount of data manipulation? The command set doesn't need to be large, but hopef…
This is exactly my point.  A data manipulation only approach would only 
have get, set, create, and delete.  Examples of conference control 
commands that are not covered by these include "create a conference", 
"delete a conference", "bring the sidebar participants back into the 
main conference", etc.  Do we need these?

My terminology use was not intended to bias the discussion - we had 
never been able to agree on the right term in the past so I tried 
another one. 
Anyway, this discussion is exactly the one I wanted to have.

If we standardize two "transports" then they have to be equivalent - 
there needs to be clear mapping between them with the same set of 
features and services covered, in my personal opinion.  This way, it is 
like SIP using both UDP and TCP.

Thanks,
Alan

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 2 Feb 2006 11:56:29 -0800

My (biased) opinion is that data manipulation (get, set, create, delete) is not enough because it does not accurately capture the complex semantics of some operations like "bring sidebar participants back into the main conference".  Data manipulation implies the intended operation; commands explicitly define the intended operation. This makes it much easier to implement more complex operations. 

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: Thursday, February 02, 2006 11:48 AM
To: Sean Olson
Cc: Chris Boulton; Cullen Jennings; Oscar Novo (JO/LMF); [email-masked]; XCON-IETF
Subject: Re: [XCON] Chair´s opinion :)

(not as chair)

Sean Olson wrote:

>Yeah, not sure I understand the terminology either ... What is the 
>purpose of the command if it does not involve some amount of data 
>manipulation? The command set doesn't need to be large, but hopefully 
>it is not just 4 commands (get, set, create, delete) ;-)
>
>  
>
This is exactly my point.  A data manipulation only approach would only have get, set, create, and delete.  Examples of conference control commands that are not covered by these include "create a conference", "delete a conference", "bring the sidebar participants back into the main conference", etc.  Do we need these?

My terminology use was not intended to bias the discussion - we had never been able to agree on the right term in the past so I tried another one. 
Anyway, this discussion is exactly the one I wanted to have.

If we standardize two "transports" then they have to be equivalent - there needs to be clear mapping between them with the same set of features and services covered, in my personal opinion.  This way, it is like SIP using both UDP and TCP.

Thanks,
Alan

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Feb 2006 15:16:39 -0500

Generally, I agree that we need more than set/get.
OTOH, I don't want a zillion operators, and an invitation for each template
to invent more.
I think we want to do two things:
	a) think hard about the data structures so set/get does what we want
	b) put a very high threshold on what constitutes an operation we
have
		a special "method" for

I'm not sure what it means to "bring sidebar participants back in the main
conference", but if it means (for an audio conference) change the mixer so
that what sidebar participants say is heard by main conference participants,
and that state is transient (that is, you want a "button" with two states
that moves them back and forth) then I want a datum ("sidebar enable") in
the sidebar data structure that can be set to true/false, and not a method.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean
Olson
Sent: Thursday, February 02, 2006 2:56 PM
To: Alan Johnston
Cc: Cullen Jennings; [email-masked]; Chris Boulton; XCON-IETF
Subject: RE: [XCON] Chair´s opinion :)

My (biased) opinion is that data manipulation (get, set, create, delete) is
not enough because it does not accurately capture the complex semantics of
some operations like "bring sidebar participants back into the main
conference".  Data manipulation implies the intended operation; commands
explicitly define the intended operation. This makes it much easier to
implement more complex operations. 

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: Thursday, February 02, 2006 11:48 AM
To: Sean Olson
Cc: Chris Boulton; Cullen Jennings; Oscar Novo (JO/LMF); [email-masked];
XCON-IETF

(not as chair)

>it is not just 4 commands (get, set, create, delete) ;-)
This is exactly my point.  A data manipulation only approach would only have
get, set, create, and delete.  Examples of conference control commands that
are not covered by these include "create a conference", "delete a
conference", "bring the sidebar participants back into the main conference",
etc.  Do we need these?

My terminology use was not intended to bias the discussion - we had never
been able to agree on the right term in the past so I tried another one. 
Anyway, this discussion is exactly the one I wanted to have.

If we standardize two "transports" then they have to be equivalent - there
needs to be clear mapping between them with the same set of features and
services covered, in my personal opinion.  This way, it is like SIP using
both UDP and TCP.

Thanks,
Alan

>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.