Subject: [XCON] Controls in the XCON data model

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 15 Jun 2010 18:28:27 +0200

Dear Oscar and all,

while playing with the data model, we found out that, in some cases, a 
more fine-grained control over the conference media would be desirable. 
To better explain this point, I will herein recall the current structure 
of the data model, which envisages the presence of a <controls> element:

******************* BEGIN excerpt from draft 
*********************************

<xs:complexType name="controls-type">
<xs:sequence>
         <xs:element name="mute" type="xs:boolean" minOccurs="0"/>
	<xs:element name="pause-video" type="xs:boolean" minOccurs="0"/>
	<xs:element name="gain" type="gain-type" minOccurs="0"/>
         <xs:element name="video-layout" type="video-layout-type" default="single-view" minOccurs="0"/>
	<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
*********************  END excerpt from draft ****************************

The above element is used, e.g., in the following data model hierarchy, in order to define controls on the
overall conference mix (on a per-medium basis):

<endpoint entity="xxx">

<media id="audio_id">
     <from-mixer name="AudioOut">
       <controls>
       <!-- controls on the mixed audio stream -->
	<gain>50<gain>
	...
       </controls>
     </from-mixer>
   </media>
</endpoint>

Indeed, we believe that the<controls>  element might also be used to arrive at a more fine-grained
(i.e. per-user and per-medium) level of control over the media involved in an XCON conference.
It would be nice to have something like the following:

<endpoint entity="xxx">

<media id="audio_id">
     <from-mixer name="AudioOut">
       <controls>
       <!-- controls on the mixed audio stream -->
	<gain>50</gain>
	...
       </controls>
     <!-- ****** BEGIN: New stuff proposed ****** -->	
       <mix-preferences>
       <include-users-list>
	<source entity="xcon-userid:[email-masked]">
	<!-- controls associated with user xcon-userid:[email-masked] -->
	<controls>
	<gain>5</gain>
	...
           </controls>
	</source>
	<source entity="xcon-userid:[email-masked]">
	<!-- controls associated with user xcon-userid:[email-masked] -->
	<controls>	
	<gain>10</gain>
	...
           </controls>
	</source>
       </include-users-list>
       <exclude-users-list>
         <source entity="xcon-userid:[email-masked]"/>
         <source entity="xcon-userid:[email-masked]"/>
       </exclude-users-list>
       </mix-preferences>
     <!-- ****** END: New stuff proposed ****** -->	

     </from-mixer>
   </media>
</endpoint>

In the example above, we introduce the possibility to manage the single contributions coming from
users participating in a conference, by re-using the same<controls>  element adopted for the overall
conference mix. By the way, we envisaged the presence of both an<include-users-list>  element and an
<exclude-users-list>, even though the latter might be equivalent to the former, with a "<mute>true</mute>"
sub-element (in the<controls>  element of the specific<source>). As you can see, this modification would require
the definition of some new elements, namely:
1.<mix-preferences>
2.<include-users-list>
3.<exclude-users-list>
4.<source>

For the sake of completeness, it stands clear that the mentioned modifications might already be applied, given
the extensibility of the current data model definition (which envisages the presence of<any>  sub-elements in the
<from-mixer>  element); nonetheless, we think it might be worth defining such new elements in an explicit fashion.

What is your feeling about this?

Cheers,

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 15 Jun 2010 13:26:05 -0400

Hey Simon,

Is there an especial reason to handle these modifications in the base  
spec, instead of as an extension?

Thanks,
--Richard

On Jun 15, 2010, at 12:28 PM, Simon Pietro Romano wrote:

> Dear Oscar and all,
>
> while playing with the data model, we found out that, in some cases,  
> a more fine-grained control over the conference media would be  
> desirable. To better explain this point, I will herein recall the  
> current structure of the data model, which envisages the presence of  
> a <controls> element:
>
> The above element is used, e.g., in the following data model  
> hierarchy, in order to define controls on the
> sub-element (in the<controls>  element of the specific<source>). As  
> you can see, this modification would require
> For the sake of completeness, it stands clear that the mentioned  
> modifications might already be applied, given
> the extensibility of the current data model definition (which  
> envisages the presence of<any>  sub-elements in the
> <from-mixer>  element); nonetheless, we think it might be worth  
> defining such new elements in an explicit fashion.
>
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xcon

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 15 Jun 2010 19:34:37 +0200

It is just for the sake of completeness. We thought we were still in 
time for this, since the data model is (almost...) ready for publication.
We ended up with this idea when impementing a number of real-world use 
cases involving the use of the CCMP, which is one of the
candidate protocols for manipulating data model fields.
Just as an exmple, if I want to filter out some users' media 
contributions from the video mix I am receiving from an XCON-compliant
conference server, I cannot currently do this, unless I fall back to 
using some kind of dirty hack.

Simon

---

From: Oscar Novo <[email-masked]>
Date: Thu, 17 Jun 2010 15:07:36 +0200

Hi Simon,

The document is already in publication request:

https://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/

Cheers,

Oscar 

-----Original Message-----
From: Simon Pietro Romano [mailto:[email-masked]] 
Sent: 15. kesäkuuta 2010 19:28
To: Oscar Novo
Cc: [email-masked]
Subject: Controls in the XCON data model

Dear Oscar and all,

while playing with the data model, we found out that, in some cases, a more fine-grained control over the conference media would be desirable. 
To better explain this point, I will herein recall the current structure of the data model, which envisages the presence of a <controls> element:

	<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType>

The above element is used, e.g., in the following data model hierarchy, in order to define controls on the overall conference mix (on a per-medium basis):

<endpoint entity="xxx">

<media id="audio_id">

Indeed, we believe that the<controls>  element might also be used to arrive at a more fine-grained (i.e. per-user and per-medium) level of control over the media involved in an XCON conference.
It would be nice to have something like the following:

<endpoint entity="xxx">

<media id="audio_id">

     </from-mixer>
   </media>
</endpoint>

In the example above, we introduce the possibility to manage the single contributions coming from users participating in a conference, by re-using the same<controls>  element adopted for the overall conference mix. By the way, we envisaged the presence of both an<include-users-list>  element and an <exclude-users-list>, even though the latter might be equivalent to the former, with a "<mute>true</mute>"
sub-element (in the<controls>  element of the specific<source>). As you can see, this modification would require the definition of some new elements, namely:
1.<mix-preferences>
2.<include-users-list>
3.<exclude-users-list>
4.<source>

For the sake of completeness, it stands clear that the mentioned modifications might already be applied, given the extensibility of the current data model definition (which envisages the presence of<any>  sub-elements in the <from-mixer>  element); nonetheless, we think it might be worth defining such new elements in an explicit fashion.

Cheers,

Simon

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 17 Jun 2010 16:55:15 +0200

Hi,

should this stop any further discussion about the data model, so?

Simon

Il giorno 17/giu/2010, alle ore 15.07, Oscar Novo <[email-masked] 
 > ha scritto:

> desirable.
> To better explain this point, I will herein recall the current  
> structure of the data model, which envisages the presence of a  
> <controls> element:
>
>    <xs:any namespace="##other" processContents="lax" minOccurs="0"  
> maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute  
> namespace="##any" processContents="lax"/> </xs:complexType>
> hierarchy, in order to define controls on the overall conference mix  
> (on a per-medium basis):
>
> <endpoint entity="xxx">
>
> <media id="audio_id">
> Indeed, we believe that the<controls>  element might also be used to  
> arrive at a more fine-grained (i.e. per-user and per-medium) level  
> of control over the media involved in an XCON conference.
> In the example above, we introduce the possibility to manage the  
> single contributions coming from users participating in a  
> conference, by re-using the same<controls>  element adopted for the  
> overall conference mix. By the way, we envisaged the presence of  
> both an<include-users-list>  element and an <exclude-users-list>,  
> even though the latter might be equivalent to the former, with a  
> "<mute>true</mute>"
> you can see, this modification would require the definition of some  
> new elements, namely:
> 1.<mix-preferences>
> 2.<include-users-list>
> 3.<exclude-users-list>
> 4.<source>
>
> modifications might already be applied, given the extensibility of  
> the current data model definition (which envisages the presence  
> of<any>  sub-elements in the <from-mixer>  element); nonetheless, we  
> think it might be worth defining such new elements in an explicit  
> fashion.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 17 Jun 2010 11:02:56 -0400

Well, it has passed Working Group *Last* Call.  So formally, the last  
chance for comments is the IETF LC, which I don't think has opened  
yet.  So everyone please get your comments on the data model in during  
IETF LC.

Thanks,
--Richard

On Jun 17, 2010, at 10:55 AM, Simon Pietro Romano wrote:

>> while playing with the data model, we found out that, in some  
>> cases, a more fine-grained control over the conference media would  
>> be desirable.
>> hierarchy, in order to define controls on the overall conference  
>> mix (on a per-medium basis):
>>
>> <endpoint entity="xxx">
>>
>> <media id="audio_id">
>> Indeed, we believe that the<controls>  element might also be used  
>> to arrive at a more fine-grained (i.e. per-user and per-medium)  
>> level of control over the media involved in an XCON conference.
>> of<any>  sub-elements in the <from-mixer>  element); nonetheless,  
>> we think it might be worth defining such new elements in an  
>> explicit fashion.
>>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 17 Jun 2010 10:35:44 -0500

Since the document has only just entered the Publication Requested
state,  I would think there's still a window for making changes if
folks agree (i.e. there's at least one more state change required
before this goes into IETF LC).

I had  also thought this document was not going to go through IETF LC
until the CCMP documents were ready since it is important that they
are aligned.

Thanks,
Mary.

On Thu, Jun 17, 2010 at 10:02 AM, Richard L. Barnes <[email-masked]> wrote:
> Well, it has passed Working Group *Last* Call.  So formally, the last chance
> for comments is the IETF LC, which I don't think has opened yet.  So
> everyone please get your comments on the data model in during IETF LC.
>
> Thanks,
> --Richard
>
>
>> Il giorno 17/giu/2010, alle ore 15.07, Oscar Novo
>> <[email-masked]> ha scritto:
>>
>>> Hi Simon,
>>>
>>> maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any"
>>> processContents="lax"/> </xs:complexType>
>>> The above element is used, e.g., in the following data model hierarchy,
>>> in order to define controls on the overall conference mix (on a per-medium
>>> basis):
>>>
>>> <endpoint entity="xxx">
>>>
>>> <media id="audio_id">
>>> arrive at a more fine-grained (i.e. per-user and per-medium) level of
>>> control over the media involved in an XCON conference.
>>> In the example above, we introduce the possibility to manage the single
>>> contributions coming from users participating in a conference, by re-using
>>> the same<controls>  element adopted for the overall conference mix. By the
>>> way, we envisaged the presence of both an<include-users-list>  element and
>>> an <exclude-users-list>, even though the latter might be equivalent to the
>>> former, with a "<mute>true</mute>"
>>> sub-element (in the<controls>  element of the specific<source>). As you
>>> can see, this modification would require the definition of some new
>>> elements, namely:
>>> 1.<mix-preferences>
>>> 2.<include-users-list>
>>> 3.<exclude-users-list>
>>> 4.<source>
>>>
>>> modifications might already be applied, given the extensibility of the
>>> current data model definition (which envisages the presence of<any>
>>>  sub-elements in the <from-mixer>  element); nonetheless, we think it might
>>> be worth defining such new elements in an explicit fashion.
>>>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 17 Jun 2010 10:45:24 -0500

The plan is to IETF LC all three of them together, so we need to  
finish up CCMP and the Examples draft ASAP.

  - Alan -

On Jun 17, 2010, at 10:35 AM, Mary Barnes <[email-masked]>  
wrote:

>>>> cases, a
>>>> structure
>>>> namespace="##any"
>>>> hierarchy,
>>>> to
>>>> single

---

From: Oscar Novo <[email-masked]>
Date: Fri, 18 Jun 2010 12:14:22 +0200

Hi,

Yes, I'll try to collect all the comments in the IETF LC.  

Cheers,

Oscar

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: 17. kesäkuuta 2010 18:03
To: Simon Pietro Romano
Cc: Oscar Novo; [email-masked]
Subject: Re: [XCON] Controls in the XCON data model

Well, it has passed Working Group *Last* Call.  So formally, the last chance for comments is the IETF LC, which I don't think has opened yet.  So everyone please get your comments on the data model in during IETF LC.

Thanks,
--Richard

On Jun 17, 2010, at 10:55 AM, Simon Pietro Romano wrote:

> <[email-masked]
>> <xs:complexType name="controls-type"> <xs:sequence>
>> single contributions coming from users participating in a conference, 
>> by re-using the same<controls>  element adopted for the overall 
>> conference mix. By the way, we envisaged the presence of both 
>> an<include-users-list>  element and an <exclude-users-list>, even 
>> though the latter might be equivalent to the former, with a 
>> "<mute>true</mute>"