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

From: "Oscar Novo" <[email-masked]>
Date: Mon, 2 Feb 2009 07:15:52 +0100

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: [email-masked] [mailto:[email-masked]] 
Sent: 30. tammikuuta 2009 20:16
To: Oscar Novo
Cc: [email-masked]
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 <[email-masked]>:

> 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: [email-masked]

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

_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

---

From: "Oscar Novo" <[email-masked]>
Date: Mon, 2 Feb 2009 07:35:55 +0100

Hi Simon,

We decide to go for that solution to avoid the (UPA) Unique Particle Attribution constraint as you said. This problem is with version 1.0. The UPA constrain might be solved with the coming new 1.1 version. We could modified the schema once the 1.1 version is released. 

Cheers,

Oscar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 30. tammikuuta 2009 20:37
To: Oscar Novo
Cc: [email-masked]
Subject: Re: [XCON] Cloning: Additional data in the data model

Hello again, Oscar. While working on the data model, we realized that the new schema you put in the draft (in appendix) does not define the XCON data model explicitely as an extension of the one contained in rfc4575. You import the mentioned schema, and you define further elements, which are the new ones introduced within XCON. This works fine, thanks to the presence of the "any" element:

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

Personally, I would have liked something more explicit, e.g.:

*****************************************************************

xmlns:info="urn:ietf:params:xml:ns:conference-info"

<xs:import namespace="urn:ietf:params:xml:ns:conference-info"   
	schemaLocation="rfc4575DataModel.xsd"/>

<xs:element name="conference-info" type="conference-type"/>

<xs:complexType name="conference-type">
  <xs:complexContent>
   <xs:extension base="info:conference-type">
    <xs:sequence>
     <xs:element name="conference-password" type="xs:string"/>
     <xs:element name="mixing-mode" type="mixing-mode-type"/>
     <xs:element name="codecs" type="codecs-type"/>
     <xs:element name="controls" type="controls-type"/>
     <xs:element name="language" type="xs:language"/>
     <xs:element name="allow-sidebars" type="xs:boolean"/>
     <xs:element name="conference-time" type="conference-time-type"/>
     <xs:element name="allow-conference-event-subscription" type="xs:boolean"/>
     <xs:element name="to-mixer" type="mixer-type"/>
     <xs:element name="provide-anonymity" type="provide-anonymity-type"/>
     <xs:element name="allow-refer-users-dynamically" type="xs:boolean"/>
     <xs:element name="allow-invite-users-dynamically" type="xs:boolean"/>
     <xs:element name="allow-remove-users-dynamically" type="xs:boolean"/>
     <xs:element name="from-mixer" type="mixer-type"/>
     <xs:element name="join-handling" type="join-handling-type"/>
     <xs:element name="user-admission-policy"  
type="user-admission-policy-type"/>
     <xs:element name="allowed-users-list" type="allowed-users-list-type"/>
     <xs:element name="deny-users-list" type="deny-users-list-type"/>
     <xs:element name="floor-information" type="floor-information-type"/>
    </xs:sequence>
   </xs:extension>
  </xs:complexContent>
</xs:complexType>

*******************************************************************************

This solution looks a bit "cleaner" to me, even though it might violate the Unique Particle Attribution constraint with some XML engines (e.g. JAXB).

What is your feeling about this?

Simon

---

From: "Oscar Novo" <[email-masked]>
Date: Mon, 2 Feb 2009 07:51:13 +0100

Hi Mary,
 
IMO, the 'parent enforceable' (or 'mother enforceable' :) ) is implicit in the 'cascaded-focus' element. If that element is defined the 'parent enforceable' relationship exist, otherwise not. 
 
Oscar
 
P.S.: unfortunately we all know how corporate web email access works... :P Enjoy your new mac! :)

________________________________

From: Mary Barnes [mailto:[email-masked]] 
Sent: 31. tammikuuta 2009 13:27
To: [email-masked]
Cc: Oscar Novo; [email-masked]
Subject: Re: [XCON] Cloning: Additional data in the data model

Oscar and Simon, 

1.  Shouldn't we call it "parent/child" or "mother/daughter" relationship ;)  Obviously, the latter is the pc choice. 

I'm also still thinking we need the "independent" info. While the logic would be handled by the conference server - e.g., can the parent be deleted?  I think the client needs to know this, so that they don't try to delete a parent and they are aware that when they get any updates, why that's happening. I also think it might be useful for debug and administration.

Thanks,
Mary
--who also apologizes for the late reply
-- and I'm traveling (with my new mac :)  and corporate email access (via secure web i/f) is so, so, so, slow.

On Fri, Jan 30, 2009 at 12:16 PM, <[email-masked]> wrote:

	Hi Oscar,

	

	
	
	Cheers,
	
	Simon

		Hi folks,

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

		Cheers,
		
		Oscar

---

From: [email-masked]
Date: Mon, 02 Feb 2009 10:10:59 +0100

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 <[email-masked]>:

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

---

From: [email-masked]
Date: Mon, 02 Feb 2009 10:12:01 +0100

Agreed ;-)

Simon

Quoting Oscar Novo <[email-masked]>:

> Hi Simon,
>
> We decide to go for that solution to avoid the (UPA) Unique Particle  
>  Attribution constraint as you said. This problem is with version   
> 1.0. The UPA constrain might be solved with the coming new 1.1   
> version. We could modified the schema once the 1.1 version is   
> released.
>
> Cheers,
>
> Oscar
>
> Hello again, Oscar. While working on the data model, we realized   
> that the new schema you put in the draft (in appendix) does not   
> define the XCON data model explicitely as an extension of the one   
> contained in rfc4575. You import the mentioned schema, and you   
> define further elements, which are the new ones introduced within   
> XCON. This works fine, thanks to the presence of the "any" element:
>
> This solution looks a bit "cleaner" to me, even though it might   
> violate the Unique Particle Attribution constraint with some XML   
> engines (e.g. JAXB).
>

---

From: "Oscar Novo" <[email-masked]>
Date: Mon, 2 Feb 2009 11:37:40 +0100

Hi,

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. 

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.

Oscar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 2. helmikuuta 2009 11:11
To: Oscar Novo
Cc: [email-masked]
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 <[email-masked]>:

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

Date: Thu, 05 Feb 2009 16:33:05 +0100
From: [email-masked]
To: Oscar Novo <[email-masked]>
Cc: [email-masked]
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

> Sent: 2. helmikuuta 2009 11:11
> To: Oscar Novo
> Cc: [email-masked]
> 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"
>>> 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.
>>>

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 12:22:53 +0100
From: "Oscar Novo" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] 
Sent: 5. helmikuuta 2009 17:33
To: Oscar Novo
Cc: [email-masked]
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

> Sent: 2. helmikuuta 2009 11:11
> To: Oscar Novo
> Cc: [email-masked]
> 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"
>>> 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.
>>>

Content-class: urn:content-classes:message
Date: Fri, 6 Feb 2009 13:01:19 -0600
From: "Mary Barnes" <[email-masked]>
To: "Oscar Novo" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar Novo
Sent: Friday, February 06, 2009 5:23 AM
To: [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: 5. helmikuuta 2009 17:33
To: Oscar Novo
Cc: [email-masked]
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

> Sent: 2. helmikuuta 2009 11:11
> To: Oscar Novo
> Cc: [email-masked]
> 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"
>>> 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.
>>>

Content-class: urn:content-classes:message
Date: Mon, 9 Feb 2009 09:11:48 +0100
From: "Oscar Novo" <[email-masked]>
To: "Mary Barnes" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [XCON] Cloning: Additional data in the data model

Mary,

Thanks for your comment.

Oscar 

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 6. helmikuuta 2009 21:01
To: Oscar Novo; [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar Novo
Sent: Friday, February 06, 2009 5:23 AM
To: [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: 5. helmikuuta 2009 17:33
To: Oscar Novo
Cc: [email-masked]
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

> Sent: 2. helmikuuta 2009 11:11
> To: Oscar Novo
> Cc: [email-masked]
> 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"
>>> 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.
>>>

Content-class: urn:content-classes:message
Date: Mon, 9 Feb 2009 17:48:06 -0500
From: "McCann Peter-A001034" <[email-masked]>
To: <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, [email-masked], [email-masked], [email-masked], Jon Peterson <[email-masked]>
Subject: [XCON] Gen-ART LC review of draft-ietf-xcon-event-package-01.txt

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). 

Please resolve these comments along with any other Last Call comments
you may receive. 

Document: draft-ietf-xcon-event-package-01.txt
Reviewer: Pete McCann
Review Date: 2009-02-09
IETF LC End Date: 2009-02-10
IESG Telechat date: (not known) 

Summary: Ready with a few minor nits.

Major issues: None

Minor issues: 

Section 5.1 contains the following text:
   When the server receives a SUBSCRIBE request (refresh or termination)
   within the associated subscription, it SHOULD send a NOTIFY request
   containing the full document using the 'application/
   xcon-conference-info+xml' content type.
Do you really want to send the full document upon termination of the
subscription?

Someone should check the XML with an automated tool to make sure it
is syntactically correct.  I did not do this.

Nits/editorial comments: 

Section 3:

OLD:
   conference instance has experimented
NEW:
   conference instance has experienced

Section 5.2:

OLD:
   received in
   notification.
NEW:
   received in the
   notification.

OLD:
   If subscriber
NEW:
   If the subscriber

Content-class: urn:content-classes:message
Date: Thu, 12 Feb 2009 16:15:17 +0100
From: "Oscar Novo" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: [XCON] CCMP comments

This is a multi-part message in MIME format.

------_=_NextPart_001_01C98D24.B6C4FCC1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Simon Pietro and others,

I was reading through the last version of your CCMP draft and I got some
notes about it. Fowolling there are my comments.

If they are not clear enough, don't hesitate to contact me and I'll try
to explain them more carefully. 

Cheers,

Oscar

------------------------------------------------------------------------
-------------------------------------------

1. Introduction:  "CCMP can use a general-purpose protocol such as HTTP
[RFC2616] to transfer domain-specific XML-encoded data objects defined
in the Conference Information Data Model for Centralized Conferencing. "

[ON] Does it mean CCMP can be use with other protocols? It's a bit
confusing reading through the document because in some parts you really
state that the use of HTTP is a must.

1. Introduction:  "CCMP follows the well-known REST (REpresentational
State Transfer) architectural style"

[ON] Well, is it really true? Maybe some clarification to this point
should be needed.

6.1 Conference Object: "When creating conferences, the XCON-URI included
by the client is only a suggestion." 

[ON] Would it not be easier if the client doesn't included any XCON-URI
and accepts the one from the server right away?

7.2 Create

[ON] It would be good if you have in the document a diagram of the
'retrieve' operation you explained in this section
[ON] I think the creation mechanism is quiet limited right now. What
about the creation of sidebars? Or the creation of other elements in the
conference? 

7.4 Delete

"A request which attempts to delete a conference object that is being
referenced by a child object is an error."
[ON] Would it not be possible to have the option to delete the
conference with all the child object included? Is a sidebar consider a
child object?

8. Protocol Operations on Conference Objects

 "blueprintsRequest/blueprintsResponse:  The blueprintsRequest is used
to ascertain the list of blueprints available at the conference server.
The blueprintsResponse returns a list of the requested blueprints, in
the form of XCON URIs."
[ON] Maybe it would be good if the blueprintsResponse returns a
description of each blueprint or ,even better, it would be possible to
defined in the blueprintsRequest the elements wanted in the response.
Sometimes just the name of the blueprint won't be enough to choose the
most convenient one. As well, it would be good if the client can defined
in the blueprintsRequest some filter criterias, for instance, blueprints
that uses the 'foo' media. 

8.2.3 Operations Request

[ON] What does the N/A means in the HTTP examples of sidebarRequest? 

8.3. Handling a CCMP Response

[ON] I got a bit confused with the set of CCMP Response Codes. Are not
the 'forbidden' and the 'operationNotAllowed' the same type of error?
And I would re-name the 'deleteFailedParent' to 'forbiddenDeleteParent'
and the 'changeFailedProtected' to 'forbiddenChangeProtected'.

8.3.3.2 Create Operation Response

"The only valid responses containing a "create" operation are a
"confResponse", a "blueprintResponse" and the "userResponse"."

[ON] what about create sidebars?

"The "blueprintRequest" containing a "create" operation has to be
considered a special operation, used by a conference server
administrator wishing to remotely add a new blueprint to the conference
server. The operation requires that the new blueprint is associated with
an XCON-URI."

[ON] I really don't get the point for that. Would it not be easier to
remove this element from the create operation if -anyway- it will be
considered a suggestion?

"If the confResponse to a "create" operation contains a response code of
"modified", along with the XCON-URI for the conference object, the
response MUST also contain the entire XML document associated with that
conference object for a "confRequest"."

[ON] why it doesn't contain just the modified part of the document?
Wouldn't it be more efficient?

"Any other response code indicates an error in the client or conference
control server (e.g., "forbidden", "badRequest") and the handling is
specific to the conference control client."
[ON] remove 'forbidden' from the sentence. 
 
8.3.3.3. Change Operation Response  
"Any other response code indicates an error in the client or conference
control server (e.g., "forbidden", "badRequest") and the handling is
specific to the conference control client."
[ON] remove 'forbidden' from the sentence. 

[ON] If the document is modified succesfully, I wouldn't send in the
response message the XML document again. I would send just an empty
satisfactory response.  

8.3.3.4 Delete Operation Response

"Any other response code indicates an error in the client or conference
control server (e.g., "forbidden", "badRequest") and the handling is
specific to the conference control client."
[ON] remove 'forbidden' from the sentence. 

10.5 Blueprints Parameter

"The "blueprints" attribute is comprised of a list of blueprints
supported by the specific conference server and includes a conference
system specific "blueprintName" and a "confObjID" in the form of an
XCON-URI for each of the blueprints."

[ON] Same comment than section 8. Would it be possible to extend the
information in the "blueprints" attribute?

11.2.3. Adding a User to a Conference

In Figure 14, it would be much neat if you use a sequence-ID to identify
the message and you get rid of repeat information. Something like:

<userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp">
        <operation>change</operation>
        <responseCode> success </responseCode>
        <confObjID> xcon:[email-masked] </confObjID>
        <confUserID> userC-confxyz987 </confUserID>
        <sequence-ID>58943</sequence-ID>
</userResponse>

NITS
--------

3. Terminology -> Change 'additon' to 'addition'

4.Rationale and Motivation -> Change 'approach must ensure sure that
all...' to 'approach must ensure that all...'

6.2 Conference Users and Participants ->last paragrah, change '<user>
attribute' to '<user> element'

8.3.1 change 'blueprintRequest' to 'blueprintsRequest' to

8.3.3.1 add a full stop at the end of the sentence. "associated with the
requested blueprint"

8.3.3.3. Change Operation Response change "used by a conference server
administrator wishing to remotely an existing blueprint in the
conference server." to "used by a conference server administrator
wishing to remotely CHANGE OR MODIFY an existing blueprint in the
conference server."

10.3 ConfUserID Parameter: change "for an "userRequest" message" to "for
A "userRequest" message"

11.1  Change "Figure 3: Getting a List of Active Coferences" to  "Figure
3: Getting a List of Active CoNferences"

11.1 Figure 4 Change "GET /confs/confid-34fg67h" to  "GET
/conf/confid-34fg67h"

11.1 Figure 5 Change " PUT /confs/confid-34fg67h/users/pippo876" to  "
PUT /conf/confid-34fg67h/users/pippo876"

11.1 Change "Figure 4: Getting a Specific Coference" to "Figure 4:
Getting a Specific CoNference"

------_=_NextPart_001_01C98D24.B6C4FCC1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>CCMP comments</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">Hi Simon Pietro and others,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">I was reading through the last version of your CCMP draft and I got some notes about it. Fowolling there are my comments.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">If they are not clear enough, don't hesitate to contact me and I'll try to explain them more carefully. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Oscar</FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">-------------------------------------------------------------------------------------------------------------------</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">1. Introduction:&nbsp; &quot;CCMP can use a general-purpose protocol such as HTTP [RFC2616] to transfer domain-specific XML-encoded data objects defined in the Conference Information Data Model for Centralized Conferencing. &quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] Does it mean CCMP can be use with other protocols? It's a bit confusing reading through the document because in some parts you really state that the use of HTTP is a must.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">1. Introduction:&nbsp; &quot;CCMP follows the well-known REST (REpresentational State Transfer) architectural style&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">[ON] Well, is it really true? Maybe some clarification to this point should be needed.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">6.1 Conference Object: &quot;When creating conferences, the XCON-URI included by the client is only a suggestion.&quot; </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">[ON] Would it not be easier if the client doesn't included any XCON-URI and accepts the one from the server right away?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">7.2 Create</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">[ON] It would be good if you have in the document a diagram of the 'retrieve' operation you explained in this section</FONT>

<BR><FONT SIZE=2 FACE="Arial">[ON] I think the creation mechanism is quiet limited right now. What about the creation of sidebars? Or the creation of other elements in the conference? </FONT></P>

<P><FONT SIZE=2 FACE="Arial">7.4 Delete</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;A request which attempts to delete a conference object that is being referenced by a child object is an error.&quot;</FONT>

<BR><FONT SIZE=2 FACE="Arial">[ON] Would it not be possible to have the option to delete the conference with all the child object included? Is a sidebar consider a child object?</FONT></P>

<P><FONT SIZE=2 FACE="Arial">8. Protocol Operations on Conference Objects</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&quot;blueprintsRequest/blueprintsResponse:&nbsp; The blueprintsRequest is used to ascertain the list of blueprints available at the conference server. The blueprintsResponse returns a list of the requested blueprints, in the form of XCON URIs.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] Maybe it would be good if the blueprintsResponse returns a description of each blueprint or ,even better, it would be possible to defined in the blueprintsRequest the elements wanted in the response. Sometimes just the name of the blueprint won't be enough to choose the most convenient one. As well, it would be good if the client can defined in the blueprintsRequest some filter criterias, for instance, blueprints that uses the 'foo' media. </FONT></P>

<P><FONT SIZE=2 FACE="Arial">8.2.3 Operations Request</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">[ON] What does the N/A means in the HTTP examples of sidebarRequest? </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">8.3. Handling a CCMP Response</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">[ON] I got a bit confused with the set of CCMP Response Codes. Are not the 'forbidden' and the 'operationNotAllowed' the same type of error? And I would re-name the 'deleteFailedParent' to 'forbiddenDeleteParent' and the 'changeFailedProtected' to 'forbiddenChangeProtected'.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">8.3.3.2 Create Operation Response</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;The only valid responses containing a &quot;create&quot; operation are a &quot;confResponse&quot;, a &quot;blueprintResponse&quot; and the &quot;userResponse&quot;.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] what about create sidebars?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;The &quot;blueprintRequest&quot; containing a &quot;create&quot; operation has to be considered a special operation, used by a conference server administrator wishing to remotely add a new blueprint to the conference server. The operation requires that the new blueprint is associated with an XCON-URI.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] I really don't get the point for that. Would it not be easier to remove this element from the create operation if -anyway- it will be considered a suggestion?</FONT></P>

<P><FONT SIZE=2 FACE="Arial">&quot;If the confResponse to a &quot;create&quot; operation contains a response code of &quot;modified&quot;, along with the XCON-URI for the conference object, the response MUST also contain the entire XML document associated with that conference object for a &quot;confRequest&quot;.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] why it doesn't contain just the modified part of the document? Wouldn't it be more efficient?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;Any other response code indicates an error in the client or conference control server (e.g., &quot;forbidden&quot;, &quot;badRequest&quot;) and the handling is specific to the conference control client.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] remove 'forbidden' from the sentence. </FONT>

<BR><FONT SIZE=2 FACE="Arial">&nbsp;</FONT>

<BR><FONT SIZE=2 FACE="Arial">8.3.3.3. Change Operation Response&nbsp; </FONT>

<BR><FONT SIZE=2 FACE="Arial">&quot;Any other response code indicates an error in the client or conference control server (e.g., &quot;forbidden&quot;, &quot;badRequest&quot;) and the handling is specific to the conference control client.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] remove 'forbidden' from the sentence. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">[ON] If the document is modified succesfully, I wouldn't send in the response message the XML document again. I would send just an empty satisfactory response.&nbsp; </FONT></P>

<P><FONT SIZE=2 FACE="Arial">8.3.3.4 Delete Operation Response</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;Any other response code indicates an error in the client or conference control server (e.g., &quot;forbidden&quot;, &quot;badRequest&quot;) and the handling is specific to the conference control client.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] remove 'forbidden' from the sentence. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">10.5 Blueprints Parameter</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;The &quot;blueprints&quot; attribute is comprised of a list of blueprints supported by the specific conference server and includes a conference system specific &quot;blueprintName&quot; and a &quot;confObjID&quot; in the form of an XCON-URI for each of the blueprints.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">[ON] Same comment than section 8. Would it be possible to extend the information in the &quot;blueprints&quot; attribute?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">11.2.3. Adding a User to a Conference</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">In Figure 14, it would be much neat if you use a sequence-ID to identify the message and you get rid of repeat information. Something like:</FONT></P>

<P><FONT SIZE=2 FACE="Arial">&lt;userResponse xmlns=&quot;urn:ietf-params:xml:ns:xcon:ccmp&quot;&gt;</FONT>

<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;operation&gt;change&lt;/operation&gt;</FONT>

<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;responseCode&gt; success &lt;/responseCode&gt;</FONT>

<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;confObjID&gt; xcon:[email-masked] &lt;/confObjID&gt;</FONT>

<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;confUserID&gt; userC-confxyz987 &lt;/confUserID&gt;</FONT>

<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;sequence-ID&gt;58943&lt;/sequence-ID&gt;</FONT>

<BR><FONT SIZE=2 FACE="Arial">&lt;/userResponse&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">NITS</FONT>

<BR><FONT SIZE=2 FACE="Arial">--------</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">3. Terminology -&gt; Change 'additon' to 'addition'</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">4.Rationale and Motivation -&gt; Change 'approach must ensure sure that all...' to 'approach must ensure that all...'</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">6.2 Conference Users and Participants -&gt;last paragrah, change '&lt;user&gt; attribute' to '&lt;user&gt; element'</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">8.3.1 change 'blueprintRequest' to 'blueprintsRequest' to</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">8.3.3.1 add a full stop at the end of the sentence. &quot;associated with the requested blueprint&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">8.3.3.3. Change Operation Response change &quot;used by a conference server administrator wishing to remotely an existing blueprint in the conference server.&quot; to &quot;used by a conference server administrator wishing to remotely CHANGE OR MODIFY an existing blueprint in the conference server.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">10.3 ConfUserID Parameter: change &quot;for an &quot;userRequest&quot; message&quot; to &quot;for A &quot;userRequest&quot; message&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">11.1&nbsp; Change &quot;Figure 3: Getting a List of Active Coferences&quot; to&nbsp; &quot;Figure 3: Getting a List of Active CoNferences&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">11.1 Figure 4 Change &quot;GET /confs/confid-34fg67h&quot; to&nbsp; &quot;GET /conf/confid-34fg67h&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">11.1 Figure 5 Change &quot; PUT /confs/confid-34fg67h/users/pippo876&quot; to&nbsp; &quot; PUT /conf/confid-34fg67h/users/pippo876&quot;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">11.1 Change &quot;Figure 4: Getting a Specific Coference&quot; to &quot;Figure 4: Getting a Specific CoNference&quot;</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C98D24.B6C4FCC1--

From: "Roni Even" <[email-masked]>
To: "'Alan Johnston'" <[email-masked]>, "'poplarbird'" <[email-masked]>
Date: Fri, 27 Feb 2009 19:01:03 +0200
Cc: [email-masked]
Subject: Re: [XCON] [Sip] Questions about the status of dual video feature in SIP

Hi, 
I had an initial document covering H.239 in SIP. The document has expired
but is a starting point

http://internet-drafts.osmirror.nl/draft-even-xcon-pnc-01.txt

As far as I know the IMTC (http://www.imtc.org/ ) has recently started some
effort to restart this work and get a common solution between the different
vendors with the objective to bring a draft to the IETF.
You can send an email to Ashish Goyal ([email-masked]) asking about the
state of the work.

Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan
Johnston
Sent: Friday, February 27, 2009 6:47 PM
To: poplarbird
Cc: [email-masked]
Subject: Re: [Sip] Questions about the status of dual video feature in SIP

Hi Yang,

Based on a little reading on H.239, it sounds like it is a conference 
feature set, which would be implemented using SIP, RTP, various SDP 
extensions for media labeling and grouping, and XCON protocols such as 
BFCP for floor control and possibly CCMP for conference control.

As such, you won't find one document that describes all these protocols, 
and most of the action happens outside of SIP.  If you have trouble 
finding some of these protocols, let me know.

Also, discussion on this would probably be most productive on the XCON list.

Thanks,
Alan

poplarbird wrote:
>
> Hi All,
>
>  
>
> I am currently working on the interworking between SIP and H323.
>
>  
>
> I had difficult in finding the status of SIP supporting dual video 
> (e.g. H.239 from a H.323 endpoint).
>
> Are there any drafts or standards working on it?
>
>  
>
> Also with the text chatting in a SIP call, if anyone can give me the 
> RFC number that would be great.
>
>  
>
> Thanks,
>
> Yang
>
> ------------------------------------------------------------------------
>
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip