Re: [XCON] Cloning: Additional data in the data model
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XCON] Cloning: Additional data in the data model



Mary,

Thanks for your comment.

Oscar 

-----Original Message-----
From: Mary Barnes [mailto:mary.barnes at nortel.com] 
Sent: 6. helmikuuta 2009 21:01
To: Oscar Novo; spromano at unina.it
Cc: xcon at ietf.org
Subject: RE: [XCON] Cloning: Additional data in the data model

Oscar,

I would prefer the explicit "Parent/child" attributes as that relates directly to "rules" for updating the conference object. Whereas, ISTM that the cascaded/focus is more around how a focus handles the conference in terms of mixer control versus a higher level control. In my view, the model we're building based on XCON FW is more designed to allow richer features and control of options, rather than media manipulation.  

The SIPPING conferencing framework does discuss cascaded mixers, but again the mixer control is not an XCON thing. It's specific to the focus as a participant as I understand it, rather than a conferencing client.  And, in the XCON model, there is a focus associated with the conference object, put it's functionality and data isn't specific to XCON. 

The focus provides the interface to the call signaling client, which may or may not be integrated with the conference control client, which can be a web based client. A client may use commands specific to a call signaling interface in some systems to Join, etc a conference - e.g., a SIP client implementing the SIP specific conferencing model, but that again is outside the scope of the XCON FW - i.e., the call signaling client has a conference ID, which is different than our Conference Object ID. The conferencing system links those in the data model. 

There is mention of cascaded mixers in some older (individual) mediactrl docs but I don't remember it (and can't find it) discussed in any of the old XCON docs  - which were originally very loosely based on the SIPPING FW.  I am the most ignorant one wrt MEDIACTRL, so perhaps one of the other CCMP authors can clarify this for us. 

Regards,
Mary. 

-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of Oscar Novo
Sent: Friday, February 06, 2009 5:23 AM
To: spromano at unina.it
Cc: xcon at ietf.org
Subject: Re: [XCON] Cloning: Additional data in the data model

Hi Simon,

I see your point. We could define the sidebar relationship in the data model instead of using the cascaded-focus concept for that. Regarding your question number one, it would be interesting to know other WG's opinions too.

Regards,

Oscar 

-----Original Message-----
From: spromano at unina.it [mailto:spromano at unina.it]
Sent: 5. helmikuuta 2009 17:33
To: Oscar Novo
Cc: xcon at ietf.org
Subject: RE: [XCON] Cloning: Additional data in the data model

Hi Oscar,

> IMO that's covered using 'cascaded-focus'. The definition of   
> 'cascaded-focus' in RFC4575 states:
>
> "This element contains a conference URI (different from the main   
> conference URI) for users that are connected to the main conference   
> as a result of focus cascading.

Though cascading might be implemented through cloning, I don't see a direct link between the "parent/child" relationship and the "main focus/cascaded focus" one.

>> So, with the 'sidebars-by-ref' you can browse from the parent to the
> child and with 'cascaded-focus' from the child to the parent.

As above: a sidebar can be obtained through cloning, but not all cloned objects have to be sidebars. Furthermore, sidebars and cascaded foci do represent different things. Let me expand a bit on this...With the current data model, with sidebars-by-ref you can browse from the main conference to the sidebars; what is missing is, inside a certain sidebar, a means to identify the main conference it belongs to. If I understand correctly, what you are proposing is to use the 'cascaded-focus' element in the sidebar conference object to identify the main conference from which the sidebar was stemmed.

I think we should go the easy way, i.e. let semantics be represented in the data model, without forcing any specific conceptual association. Stated in simple terms:

i) do we need to express a (general) parent/child relationship? If so, let's make it explicit in the data model;

ii) do we need to know whether a specified conf object is a sidebar of a different one? If so, let's make it explicit in the data model.

I would like to gather other folks'opinions on the subject.

Cheers,

Simon


>
> Oscar
>
> -----Original Message-----
> From: spromano at unina.it [mailto:spromano at unina.it]
> Sent: 2. helmikuuta 2009 11:11
> To: Oscar Novo
> Cc: xcon at ietf.org
> Subject: RE: [XCON] Cloning: Additional data in the data model
>
> Hi Oscar,
>
> what I was suggesting is to add some means to detect whether a   
> certain conference is a child of a parent conference; similarly,   
> with sidebars, I would like to know if a certain conference object   
> actually represents a sidebar of another conference. The two   
> mechanisms you mention ('cascaded-focus' and 'sidebars-by-ref')   
> allow you to "browse"
> conference objects in exactly the opposite direction. What is your   
> feeling about that?
>
> Cheers,
>
> Simon
>
> Quoting Oscar Novo <oscar.novo at ericsson.com>:
>
>> Hi Simon,
>>
>> Thanks for your reply.
>> Regarding the new attributes you proposed. I might be wrong but I 
>> think the father/son relationship is already covered with the 
>> 'cascaded-focus' element and the conference/sidebar relationship is 
>> covered with the 'sidebars-by-ref'. What do you think about that?
>>
>> Thanks,
>>
>> Oscar
>>
>> -----Original Message-----
>> From: spromano at unina.it [mailto:spromano at unina.it]
>> Sent: 30. tammikuuta 2009 20:16
>> To: Oscar Novo
>> Cc: xcon at ietf.org
>> Subject: Re: [XCON] Cloning: Additional data in the data model
>>
>> Hi Oscar,
>>
>> sorry for the late reply. IMHO, we might need in the data model:
>>
>> 1. information about the father/son relationship. This might be an 
>> attribute, e.g.:
>>
>> <xs:attribute name="fatherEntity" type="xs:anyURI" use="optional"/>
>>
>> 2. information about the conference/sidebar relationship, e.g.:
>>
>> <xs:attribute name="sidebarOf" type="xs:anyURI" use="optional"/>.
>>
>> As to the "parent enforceable" relationship, I would leave it outside 
>> of the data model.
>>
>> Cheers,
>>
>> Simon
>>
>>
>> Quoting Oscar Novo <oscar.novo at ericsson.com>:
>>
>>> Hi folks,
>>>
>>> In IETF-73 has been a proposal to expand the data model to support 
>>> the cloning method defined in the framework. At the moment, the data 
>>> model supports the cloning method though the 'cascaded-focus'
>>> element which contains a 'parent' conference URI but it might be 
>>> needed to add few more elements to be align with CCMP.
>>>
>>> Some elements that could be added are:
>>>
>>> - An element that contains all the 'non-independent' children 
>>> conferences
>>> - A policy attribute/element that indicates the "parent enforceable"
>>> of every element. However, it would make more sense to add it in a 
>>> draft that discusses conference policies.
>>>
>>> It would be nice to know the opinion of the WG whether we want to 
>>> support entirely this property or not.
>>>
>>> Cheers,
>>>
>>> Oscar
>>>
>>>
>>>
>>
>>
>>
>> --
>>                              _\\|//_
>>                              ( 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: spromano at unina.it
>>
>>      <<Molti mi dicono che lo scoraggiamento è l'alibi degli
>>     idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                           oooO
>>     ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>                            \ (    (   )
>>                             \_)    ) /
>>                                   (_/
>>
>>
>
>
>
> --
>                              _\\|//_
>                              ( 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: spromano at unina.it
>
>      <<Molti mi dicono che lo scoraggiamento è l'alibi degli
>     idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                           oooO
>     ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                            \ (    (   )
>                             \_)    ) /
>                                   (_/
>
>



-- 
                             _\\|//_
                             ( 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: spromano at unina.it

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

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.