Subject: [XCON] Comments on draft-boulton-xcon-media-template-01

From: "Orit Levin" <[email-masked]>
Date: Mon, 3 Oct 2005 16:01:55 -0700

Guys,
I would like to share my thoughts on the current "templates" draft
direction.
 
1. The XML Schema Definition (e.g. 3.1.7)
If my understanding is correct, the XML Schema definition in 3.1.7 is
the single common XML schema definition which all the "templates" in the
draft are defined from.
 
In order to be consistent with the current Framework terminology, I
would say that "the XML Schema definition in 3.1.7 is the single
template defined by this draft, which all the listed "blueprints" in
this draft (e.g. basic-audio, advanced-audio, etc.) are instantiated
from".
 
Conceptually speaking, the proposed approach looks to me as a definition
of a "stencil" like UI-oriented format to be populated and communicated
"as is" between a client and a server. If this is the idea, wouldn't it
be easier to just use one of the existing protocols for UI
representation?
 
I am not a great fan of this approach ;-) but it can be useful for
unintelligent clients and would avoid the need for updating the client
SW with every new template definition or extension. I will not object to
this approach as long as we allow for different approaches (i.e.
additional template types) as well ;-). 
 
2. The XML Definitions (e.g. 3.1.6, 3.2.6, etc.)
Clearly from the XML, each of these XML documents is an example of a
"blueprint" that needs to be defined by a specific conferencing system
according to its administrative choices and capabilities and not by the
IETF ;-) This also makes the whole approach work since the actual MIN
and MAX values of the parameters are defined by the "blueprint" and not
by the "template".
 
3. Do we really need a floor control in the basic blueprints?
It is perfectly OK to have the floor control definitions in the template
but would we typically need to have the floor control settings in the
basic "blueprints"? This is just a question since anyway the "blueprint"
definitions in  the document should be examples only.
 
4. Parameters that exist in the conference event package
In cases where the template parameters, controls, etc. correspond to
more general elements defined in the Conference package, it will be very
helpful to describe the relationships between/among them. For example,
the sum of the participants of each role in the blueprint corresponds to
the number of users in the conference package.
 
Thanks,
Orit.
_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: [email-masked]
Date: Tue, 4 Oct 2005 12:33:54 -0500

Hello Orit,
 
Thanks for the review and comments on the draft. Replines inline.
Umesh

________________________________

	From: ext Orit Levin [mailto:[email-masked]] 
	Sent: Monday, October 03, 2005 6:02 PM
	To: XCON
	Cc: Chris Boulton; Chandra Umesh (Nokia-NRC/Dallas)
	Subject: Comments on draft-boulton-xcon-media-template-01

	Guys,
	I would like to share my thoughts on the current "templates"
draft direction.

	If my understanding is correct, the XML Schema definition in
3.1.7 is the single common XML schema definition which all the
"templates" in the draft are defined from.
	 
	In order to be consistent with the current Framework
terminology, I would say that "the XML Schema definition in 3.1.7 is the
single template defined by this draft, which all the listed "blueprints"
in this draft (e.g. basic-audio, advanced-audio, etc.) are instantiated
from".
	[[Umesh]] I think you would have different templates for
different conference scenarios like basic audio, basic audio/video etc.
The way it would work is the moderator/creator of the conference would
use a particular template based on the media being used in the
conference and creates the blueprint. Ofcourse each conference template
has functionalties which the moderator or creator of the conference
might not want to use during the conference. But there will be different
templates for different conferece senarios from which you instantiate
the blueprint. 
	 
	Any reason why you would want to have just one template from
which you could instantiate different type of conference scenarios. I
guess may be we didnt understand this point clearly.

	Conceptually speaking, the proposed approach looks to me as a
definition of a "stencil" like UI-oriented format to be populated and
communicated "as is" between a client and a server. If this i the idea,
wouldn't it be easier to just use one of the existing protocols for UI
representation?
	 
	I am not a great fan of this approach ;-) but it can be useful
for unintelligent clients and would avoid the need for updating the
client SW with every new template definition or extension. I will not
object to this approach as long as we allow for different approaches
(i.e. additional template types) as well ;-).  
	 
	2. The XML Definitions (e.g. 3.1.6, 3.2.6, etc.)
	Clearly from the XML, each of these XML documents is an example
of a "blueprint" that needs to be defined by a specific conferencing
system according to its administrative choices and capabilities and not
by the IETF ;-) This also makes the whole approach work since the actual
MIN and MAX values of the parameters are defined by the "blueprint" and
not by the "template".
	[[Umesh]] What we have section 3.1.6, 3.2.6 are just examples of
an conference scenario. What ulimtaely would be in the draft would the
XML schema which are the templates for difference conference scenarios.
You are right when you say that the conferencing system admin would
define the values from the templates which would be the blueprint. I am
assuming the confusion is there since we have not provided the Schema
(which is the actual template) and provided just the blueprint (or an
examle).
	 
	3. Do we really need a floor control in the basic blueprints?
	It is perfectly OK to have the floor control definitions in the
template but would we typically need to have the floor control settings
in the basic "blueprints"? This is just a question since anyway the
"blueprint" definitions in  the document should be examples only.
	[[Umesh]] The reason we added floor control in the basic
templates (or basic audio) would be for conference sceanrios like PTT.
And also its possible to disable the floor control for a given
conference scenario (as decided by the administrator of the conference).
I would think that the floor control settings in the blueprints would be
useful since if the end point UI is taking information from the
blueprint (to display the UI), it could use the floor control setting to
grey out the talk button on the UI incase the end point doesnt have the
floor to talk. But i guess we need to discuss more on this point.
	 
	4. Parameters that exist in the conference event package
	In cases where the template parameters, controls, etc.
correspond to more general elements defined in the Conference package,
it will be very helpful to describe the relationships between/among
them. For example, the sum of the participants of each role in the
blueprint corresponds to the number of users in the conference package.
	[[Umesh]] Agreed.

	Thanks,
	Orit.

---

From: "Orit Levin" <[email-masked]>
Date: Tue, 4 Oct 2005 12:39:02 -0700

Umesh,
Based on your reply I think that only a couple of additions and
clarifications to the draft will make it much more explicit:

1. First, I do think that we do need more than a single template. May be
even a dedicated one for each media type. Yes, please, add a template
XML definition (.xsd) for each template in the draft. I suspect that
once we have them defined, we will see that because of the
"stencil-like" approach - they all will look very much the same. (On
contrary, had you chosen the semantic oriented approach, the templates
could look very different for different conference types: "basic
interactive audio&video" vs. "e-learning application sharing with
moderator", etc.)

2. Yes, please, rename the current "XML definition" sections to
"Blueprint Example". This will avoid possible future confusions.

Thanks a lot,
Orit.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, October 04, 2005 10:34 AM
> To: Orit Levin; [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-boulton-xcon-media-template-01
> 
> Hello Orit,
>  
> 3.1.7 is the single common XML schema definition which all 
> the "templates" in the draft are defined from.
> 	 
> terminology, I would say that "the XML Schema definition in 
> 3.1.7 is the single template defined by this draft, which all 
> the listed "blueprints"
> in this draft (e.g. basic-audio, advanced-audio, etc.) are 
> instantiated from".
> 	[[Umesh]] I think you would have different templates 
> for different conference scenarios like basic audio, basic 
> audio/video etc.
> The way it would work is the moderator/creator of the 
> conference would use a particular template based on the media 
> being used in the conference and creates the blueprint. 
> Ofcourse each conference template has functionalties which 
> the moderator or creator of the conference might not want to 
> use during the conference. But there will be different 
> templates for different conferece senarios from which you 
> instantiate the blueprint. 
> 	 
> 	Any reason why you would want to have just one template 
> from which you could instantiate different type of conference 
> scenarios. I guess may be we didnt understand this point clearly.
> 	 
> 	 
> 	Conceptually speaking, the proposed approach looks to 
> me as a definition of a "stencil" like UI-oriented format to 
> be populated and communicated "as is" between a client and a 
> server. If this i the idea, wouldn't it be easier to just use 
> one of the existing protocols for UI representation?
> 	 
> 	I am not a great fan of this approach ;-) but it can be 
> useful for unintelligent clients and would avoid the need for 
> updating the client SW with every new template definition or 
> extension. I will not object to this approach as long as we 
> allow for different approaches (i.e. additional template 
> types) as well ;-).  
> 	 
> 	Clearly from the XML, each of these XML documents is an 
> example of a "blueprint" that needs to be defined by a 
> specific conferencing system according to its administrative 
> choices and capabilities and not by the IETF ;-) This also 
> makes the whole approach work since the actual MIN and MAX 
> values of the parameters are defined by the "blueprint" and 
> not by the "template".
> 	[[Umesh]] What we have section 3.1.6, 3.2.6 are just 
> examples of an conference scenario. What ulimtaely would be 
> in the draft would the XML schema which are the templates for 
> difference conference scenarios.
> You are right when you say that the conferencing system admin 
> would define the values from the templates which would be the 
> blueprint. I am assuming the confusion is there since we have 
> not provided the Schema (which is the actual template) and 
> provided just the blueprint (or an examle).
> 	 
> 	It is perfectly OK to have the floor control 
> definitions in the template but would we typically need to 
> have the floor control settings in the basic "blueprints"? 
> This is just a question since anyway the "blueprint" 
> 	[[Umesh]] The reason we added floor control in the 
> basic templates (or basic audio) would be for conference 
> sceanrios like PTT.
> And also its possible to disable the floor control for a 
> given conference scenario (as decided by the administrator of 
> the conference).
> I would think that the floor control settings in the 
> blueprints would be useful since if the end point UI is 
> taking information from the blueprint (to display the UI), it 
> could use the floor control setting to grey out the talk 
> button on the UI incase the end point doesnt have the floor 
> to talk. But i guess we need to discuss more on this point.
> 	 
> correspond to more general elements defined in the Conference 
> package, it will be very helpful to describe the 
> relationships between/among them. For example, the sum of the 
> participants of each role in the blueprint corresponds to the 
> number of users in the conference package.
> 	[[Umesh]] Agreed.
> 	  
> 	 
> 	 
> 	Thanks,
> 	Orit.
> 
>

---

From: [email-masked]
Date: Tue, 4 Oct 2005 15:00:00 -0500

Orit,

Reply inline..

Thanks

Umesh 

-----Original Message-----
From: ext Orit Levin [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2005 2:39 PM
To: Chandra Umesh (Nokia-NRC/Dallas); [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-boulton-xcon-media-template-01

Umesh,

[Umesh] I guess there would be an explosion of templates if we take a
semantic based approach in desigining templates. By semantic based
approach you mean having a specific template for a specific scenario,
for example e-learning application sharing with moderator or Audio/video
conference with text. That is why we tried to provide capabilities in
the templates so that you could use templates for specific scenarios,
case in point the floor control support which could be disabled if not
required. The aim is to have templates defined in such a way that you
could derive max conference scenarios out of it. The conference scenario
document was taken into consideration when coming up with templates (and
I think we still need to cover some scenarios).

Thanks a lot,
Orit.

> Thanks for the review and comments on the draft. Replines inline.
terminology, I 
> would say that "the XML Schema definition in
> 3.1.7 is the single template defined by this draft, which all the 
> listed "blueprints"
different 
> conference scenarios like basic audio, basic audio/video etc.

> conference and creates the blueprint.
> Ofcourse each conference template has functionalties which the 
> moderator or creator of the conference might not want to use during 
> the conference. But there will be different templates for different 
> conferece senarios from which you instantiate the blueprint.
> 	 
which 
> you could instantiate different type of conference scenarios. I guess 
> may be we didnt understand this point clearly.
> 	 
> 	 
> communicated "as is" between a client and a server. If this i the 
> idea, wouldn't it be easier to just use one of the existing protocols 
> for UI representation?
> 	 
for 

> SW with every new template definition or extension. I will not object 
> to this approach as long as we allow for different approaches (i.e. 
> additional template
> types) as well ;-).  
> 	 
of a 

> according to its administrative choices and capabilities and not by 
> the IETF ;-) This also makes the whole approach work since the actual 
> MIN and MAX values of the parameters are defined by the "blueprint" 
> and not by the "template".
an 
> conference scenario. What ulimtaely would be in the draft would the 
> define the values from the templates which would be the blueprint. I 
> am assuming the confusion is there since we have not provided the 
> Schema (which is the actual template) and provided just the blueprint 
> (or an examle).
> 	 
> template but would we typically need to have the floor control 
> settings in the basic "blueprints"?
templates 
> (or basic audio) would be for conference sceanrios like PTT.
> I would think that the floor control settings in the blueprints would 
> be useful since if the end point UI is taking information from the 
> blueprint (to display the UI), it could use the floor control setting 
> to grey out the talk button on the UI incase the end point doesnt have

> the floor to talk. But i guess we need to discuss more on this point.
>