Re: [XCON] Cloning: Additional data in the data model
"Oscar Novo" <oscar.novo@ericsson.com> Mon, 02 February 2009 10:43 UTC
Return-Path: <xcon-bounces@ietf.org>
X-Original-To: xcon-archive@megatron.ietf.org
Delivered-To: ietfarch-xcon-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DDE3A6A4D; Mon, 2 Feb 2009 02:43:18 -0800 (PST)
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688333A6A0C for <xcon@core3.amsl.com>; Mon, 2 Feb 2009 02:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.166
X-Spam-Level:
X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPptyLZWvf9g for <xcon@core3.amsl.com>; Mon, 2 Feb 2009 02:43:15 -0800 (PST)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 423173A68A6 for <xcon@ietf.org>; Mon, 2 Feb 2009 02:43:15 -0800 (PST)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 060E920CE1; Mon, 2 Feb 2009 11:42:54 +0100 (CET)
X-AuditID: c1b4fb3c-adf5ebb00000304c-00-4986cda169b9
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 69F4D20DE4; Mon, 2 Feb 2009 11:40:33 +0100 (CET)
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 11:37:41 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 02 Feb 2009 11:37:40 +0100
Message-ID: <9520E66537CC4941994C518E3E21091C47448A@esealmw105.eemea.ericsson.se>
In-Reply-To: <20090202101059.5v63j5rd9wcw0wog@webmail.unina.it>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [XCON] Cloning: Additional data in the data model
Thread-Index: AcmFFlYTAO+XOooyT7ycEJZYKiJwMQAAZsqw
References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se><20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it><9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se> <20090202101059.5v63j5rd9wcw0wog@webmail.unina.it>
From: Oscar Novo <oscar.novo@ericsson.com>
To: spromano@unina.it
X-OriginalArrivalTime: 02 Feb 2009 10:37:41.0280 (UTC) FILETIME=[465F4200:01C98522]
X-Brightmail-Tracker: AAAAAA==
Cc: xcon@ietf.org
Subject: Re: [XCON] Cloning: Additional data in the data model
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xcon-bounces@ietf.org
Errors-To: xcon-bounces@ietf.org
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: spromano@unina.it [mailto:spromano@unina.it] Sent: 2. helmikuuta 2009 11:11 To: Oscar Novo Cc: xcon@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@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@unina.it [mailto:spromano@unina.it] > Sent: 30. tammikuuta 2009 20:16 > To: Oscar Novo > Cc: xcon@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@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@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@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@ietf.org https://www.ietf.org/mailman/listinfo/xcon Return-Path: <spromano@unina.it> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C303A6AA2 for <xcon@core3.amsl.com>; Thu, 5 Feb 2009 07:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyGV62b-SI8Y for <xcon@core3.amsl.com>; Thu, 5 Feb 2009 07:33:28 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 7DA843A698E for <xcon@ietf.org>; Thu, 5 Feb 2009 07:33:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id n15FX5ug025606; Thu, 5 Feb 2009 16:33:05 +0100 Received: from 143.225.229.178 ([143.225.229.178]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 05 Feb 2009 16:33:05 +0100 Message-ID: <20090205163305.mdforuj5bko88sg0@webmail.unina.it> Date: Thu, 05 Feb 2009 16:33:05 +0100 From: spromano@unina.it To: Oscar Novo <oscar.novo@ericsson.com> References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se><20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it><9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se> <20090202101059.5v63j5rd9wcw0wog@webmail.unina.it> <9520E66537CC4941994C518E3E21091C47448A@esealmw105.eemea.ericsson.se> In-Reply-To: <9520E66537CC4941994C518E3E21091C47448A@esealmw105.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/8954/Thu Feb 5 11:54:02 2009 on webmail.unina.it X-Virus-Status: Clean Cc: xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 05 Feb 2009 15:33:29 -0000 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@unina.it [mailto:spromano@unina.it] > Sent: 2. helmikuuta 2009 11:11 > To: Oscar Novo > Cc: xcon@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@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@unina.it [mailto:spromano@unina.it] >> Sent: 30. tammikuuta 2009 20:16 >> To: Oscar Novo >> Cc: xcon@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@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@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@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@unina.it <<Molti mi dicono che lo scoraggiamento è l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ Return-Path: <oscar.novo@ericsson.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E08B3A6BB8 for <xcon@core3.amsl.com>; Fri, 6 Feb 2009 03:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFOTn1R6i8EV for <xcon@core3.amsl.com>; Fri, 6 Feb 2009 03:43:29 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 808243A6A8C for <xcon@ietf.org>; Fri, 6 Feb 2009 03:43:28 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 01D9E21FD0; Fri, 6 Feb 2009 12:43:27 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-98-498c1e143e1c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1257522210; Fri, 6 Feb 2009 12:25:08 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 12:22:54 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 12:22:53 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C546614@esealmw105.eemea.ericsson.se> In-Reply-To: <20090205163305.mdforuj5bko88sg0@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning: Additional data in the data model Thread-Index: AcmHpw3XStxyq/S+ShmW1vVgNqKioQApEqeA References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se><20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it><9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se><20090202101059.5v63j5rd9wcw0wog@webmail.unina.it><9520E66537CC4941994C518E3E21091C47448A@esealmw105.eemea.ericsson.se> <20090205163305.mdforuj5bko88sg0@webmail.unina.it> From: "Oscar Novo" <oscar.novo@ericsson.com> To: <spromano@unina.it> X-OriginalArrivalTime: 06 Feb 2009 11:22:54.0208 (UTC) FILETIME=[410E3800:01C9884D] X-Brightmail-Tracker: AAAAAA= Cc: xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 Feb 2009 11:43:30 -0000 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@unina.it [mailto:spromano@unina.it] Sent: 5. helmikuuta 2009 17:33 To: Oscar Novo Cc: xcon@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@unina.it [mailto:spromano@unina.it] > Sent: 2. helmikuuta 2009 11:11 > To: Oscar Novo > Cc: xcon@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@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@unina.it [mailto:spromano@unina.it] >> Sent: 30. tammikuuta 2009 20:16 >> To: Oscar Novo >> Cc: xcon@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@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@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@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@unina.it <<Molti mi dicono che lo scoraggiamento è l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ Return-Path: <mary.barnes@nortel.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2633B3A6BE0 for <xcon@core3.amsl.com>; Fri, 6 Feb 2009 11:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IklSeLyYeUZi for <xcon@core3.amsl.com>; Fri, 6 Feb 2009 11:04:44 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A9AB43A6BDE for <xcon@ietf.org>; Fri, 6 Feb 2009 11:04:44 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n16J4gJ19170; Fri, 6 Feb 2009 19:04:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 13:01:19 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1C1EADEE@zrc2hxm0.corp.nortel.com> In-Reply-To: <9520E66537CC4941994C518E3E21091C546614@esealmw105.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning: Additional data in the data model Thread-Index: AcmHpw3XStxyq/S+ShmW1vVgNqKioQApEqeAAA2w2qAReferences: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se><20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it><9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se><20090202101059.5v63j5rd9wcw0wog@webmail.unina.it><9520E66537CC4941994C518E3E21091C47448A@esealmw105.eemea.ericsson.se><20090205163305.mdforuj5bko88sg0@webmail.unina.it> <9520E66537CC4941994C518E3E21091C546614@esealmw105.eemea.ericsson.se> From: "Mary Barnes" <mary.barnes@nortel.com> To: "Oscar Novo" <oscar.novo@ericsson.com>, <spromano@unina.it> Cc: xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 06 Feb 2009 19:04:46 -0000 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@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Oscar Novo Sent: Friday, February 06, 2009 5:23 AM To: spromano@unina.it Cc: xcon@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@unina.it [mailto:spromano@unina.it] Sent: 5. helmikuuta 2009 17:33 To: Oscar Novo Cc: xcon@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@unina.it [mailto:spromano@unina.it] > Sent: 2. helmikuuta 2009 11:11 > To: Oscar Novo > Cc: xcon@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@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@unina.it [mailto:spromano@unina.it] >> Sent: 30. tammikuuta 2009 20:16 >> To: Oscar Novo >> Cc: xcon@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@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@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@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@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@ietf.org https://www.ietf.org/mailman/listinfo/xcon Return-Path: <oscar.novo@ericsson.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253F93A69AA for <xcon@core3.amsl.com>; Mon, 9 Feb 2009 00:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLbJBbwoYvZV for <xcon@core3.amsl.com>; Mon, 9 Feb 2009 00:11:49 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5FA2E3A6993 for <xcon@ietf.org>; Mon, 9 Feb 2009 00:11:49 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C299A20788; Mon, 9 Feb 2009 09:11:49 +0100 (CET) X-AuditID: c1b4fb3c-a9a82bb00000127c-8b-498fe5456711 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81A2A520003; Mon, 9 Feb 2009 09:11:49 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 09:11:49 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2009 09:11:48 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C546E09@esealmw105.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1C1EADEE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning: Additional data in the data model Thread-Index: AcmHpw3XStxyq/S+ShmW1vVgNqKioQApEqeAAA2w2qAAgtoZEA= References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se><20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it><9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se><20090202101059.5v63j5rd9wcw0wog@webmail.unina.it><9520E66537CC4941994C518E3E21091C47448A@esealmw105.eemea.ericsson.se><20090205163305.mdforuj5bko88sg0@webmail.unina.it> <9520E66537CC4941994C518E3E21091C546614@esealmw105.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1C1EADEE@zrc2hxm0.corp.nortel.com> From: "Oscar Novo" <oscar.novo@ericsson.com> To: "Mary Barnes" <mary.barnes@nortel.com>, <spromano@unina.it> X-OriginalArrivalTime: 09 Feb 2009 08:11:49.0352 (UTC) FILETIME=[0EB54680:01C98A8E] X-Brightmail-Tracker: AAAAAA= Cc: xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Feb 2009 08:11:51 -0000 Mary, Thanks for your comment. Oscar -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 6. helmikuuta 2009 21:01 To: Oscar Novo; spromano@unina.it Cc: xcon@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@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Oscar Novo Sent: Friday, February 06, 2009 5:23 AM To: spromano@unina.it Cc: xcon@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@unina.it [mailto:spromano@unina.it] Sent: 5. helmikuuta 2009 17:33 To: Oscar Novo Cc: xcon@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@unina.it [mailto:spromano@unina.it] > Sent: 2. helmikuuta 2009 11:11 > To: Oscar Novo > Cc: xcon@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@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@unina.it [mailto:spromano@unina.it] >> Sent: 30. tammikuuta 2009 20:16 >> To: Oscar Novo >> Cc: xcon@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@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@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@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@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@ietf.org https://www.ietf.org/mailman/listinfo/xcon Return-Path: <pete.mccann@motorola.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9C528C23E; Mon, 9 Feb 2009 14:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55de+nOJO2VS; Mon, 9 Feb 2009 14:48:17 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with SMTP id B04C328C23F; Mon, 9 Feb 2009 14:48:16 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-10.tower-55.messagelabs.com!1234219692!94103192!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 2830 invoked from network); 9 Feb 2009 22:48:12 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-10.tower-55.messagelabs.com with SMTP; 9 Feb 2009 22:48:12 -0000 Received: from il27exr01.cig.mot.com (il27exr01.mot.com [10.17.196.70]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id n19Mm7jf000815; Mon, 9 Feb 2009 15:48:12 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id n19Mm6Pj019371; Mon, 9 Feb 2009 16:48:06 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id n19Mm6hC019367; Mon, 9 Feb 2009 16:48:06 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2009 17:48:06 -0500 Message-ID: <BE4B07D4197BF34EB3B753DD34EBCD130354B19E@de01exm67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART LC review of draft-ietf-xcon-event-package-01.txt Thread-Index: AcmLCHjgXf4qsf+FSCGEgRthwM1P4Q= From: "McCann Peter-A001034" <pete.mccann@motorola.com> To: <draft-ietf-xcon-event-package@tools.ietf.org> X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 09 Feb 2009 15:00:39 -0800 Cc: Cullen Jennings <fluffy@cisco.com>, gen-art@ietf.org, xcon-chairs@tools.ietf.org, xcon@ietf.org, Jon Peterson <jon.peterson@neustar.biz> Subject: [XCON] Gen-ART LC review of draft-ietf-xcon-event-package-01.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Feb 2009 22:48:18 -0000 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 Return-Path: <oscar.novo@ericsson.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41453A68A1 for <xcon@core3.amsl.com>; Thu, 12 Feb 2009 07:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEN5EBlAaS1k for <xcon@core3.amsl.com>; Thu, 12 Feb 2009 07:15:15 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 94BBE3A69E4 for <xcon@ietf.org>; Thu, 12 Feb 2009 07:15:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 023EB21469; Thu, 12 Feb 2009 16:15:19 +0100 (CET) X-AuditID: c1b4fb3e-ac8bcbb000001315-47-49943d064dbb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2F7621451; Thu, 12 Feb 2009 16:15:18 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 16:15:18 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98D24.B6C4FCC1" Date: Thu, 12 Feb 2009 16:15:17 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C5C2916@esealmw105.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCMP comments Thread-Index: AcmNJLYslyT5WL8oQa6hhYMVuzfPaA= From: "Oscar Novo" <oscar.novo@ericsson.com> To: <spromano@unina.it>, <xcon@ietf.org> X-OriginalArrivalTime: 12 Feb 2009 15:15:18.0306 (UTC) FILETIME=[B6DD3820:01C98D24] X-Brightmail-Tracker: AAAAAA= Cc: hgs+xcon@cs.columbia.edu Subject: [XCON] CCMP comments X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 12 Feb 2009 15:15:16 -0000 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:confxyz987@example.com </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: "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. "</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: "CCMP follows the well-known REST (REpresentational State Transfer) architectural style"</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: "When creating conferences, the XCON-URI included by the client is only a suggestion." </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">"A request which attempts to delete a conference object that is being referenced by a child object is an error."</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"> "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."</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">"The only valid responses containing a "create" operation are a "confResponse", a "blueprintResponse" and the "userResponse"."</FONT></P> <P><FONT SIZE=2 FACE="Arial">[ON] what about create sidebars?</FONT> </P> <P><FONT SIZE=2 FACE="Arial">"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."</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">"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"."</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">"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."</FONT></P> <P><FONT SIZE=2 FACE="Arial">[ON] remove 'forbidden' from the sentence. </FONT> <BR><FONT SIZE=2 FACE="Arial"> </FONT> <BR><FONT SIZE=2 FACE="Arial">8.3.3.3. Change Operation Response </FONT> <BR><FONT SIZE=2 FACE="Arial">"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."</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. </FONT></P> <P><FONT SIZE=2 FACE="Arial">8.3.3.4 Delete Operation Response</FONT> </P> <P><FONT SIZE=2 FACE="Arial">"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."</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">"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."</FONT></P> <P><FONT SIZE=2 FACE="Arial">[ON] Same comment than section 8. Would it be possible to extend the information in the "blueprints" 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"><userResponse xmlns="urn:ietf-params:xml:ns:xcon:ccmp"></FONT> <BR><FONT SIZE=2 FACE="Arial"> <operation>change</operation></FONT> <BR><FONT SIZE=2 FACE="Arial"> <responseCode> success </responseCode></FONT> <BR><FONT SIZE=2 FACE="Arial"> <confObjID> xcon:confxyz987@example.com </confObjID></FONT> <BR><FONT SIZE=2 FACE="Arial"> <confUserID> userC-confxyz987 </confUserID></FONT> <BR><FONT SIZE=2 FACE="Arial"> <sequence-ID>58943</sequence-ID></FONT> <BR><FONT SIZE=2 FACE="Arial"></userResponse></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 -> Change 'additon' to 'addition'</FONT> </P> <P><FONT SIZE=2 FACE="Arial">4.Rationale and Motivation -> 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 ->last paragrah, change '<user> attribute' to '<user> 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. "associated with the requested blueprint"</FONT> </P> <P><FONT SIZE=2 FACE="Arial">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."</FONT></P> <P><FONT SIZE=2 FACE="Arial">10.3 ConfUserID Parameter: change "for an "userRequest" message" to "for A "userRequest" message"</FONT> </P> <P><FONT SIZE=2 FACE="Arial">11.1 Change "Figure 3: Getting a List of Active Coferences" to "Figure 3: Getting a List of Active CoNferences"</FONT> </P> <P><FONT SIZE=2 FACE="Arial">11.1 Figure 4 Change "GET /confs/confid-34fg67h" to "GET /conf/confid-34fg67h"</FONT> </P> <P><FONT SIZE=2 FACE="Arial">11.1 Figure 5 Change " PUT /confs/confid-34fg67h/users/pippo876" to " PUT /conf/confid-34fg67h/users/pippo876"</FONT> </P> <P><FONT SIZE=2 FACE="Arial">11.1 Change "Figure 4: Getting a Specific Coference" to "Figure 4: Getting a Specific CoNference"</FONT> </P> <BR> <BR> <BR> <BR> </BODY> </HTML> ------_=_NextPart_001_01C98D24.B6C4FCC1-- Return-Path: <ron.even.tlv@gmail.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEB928C16D for <xcon@core3.amsl.com>; Fri, 27 Feb 2009 09:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNiAhDb6Nq2F for <xcon@core3.amsl.com>; Fri, 27 Feb 2009 09:02:32 -0800 (PST) Received: from mail-fx0-f164.google.com (mail-fx0-f164.google.com [209.85.220.164]) by core3.amsl.com (Postfix) with ESMTP id 91B383A6B10 for <xcon@ietf.org>; Fri, 27 Feb 2009 09:02:31 -0800 (PST) Received: by fxm8 with SMTP id 8so597412fxm.13 for <xcon@ietf.org>; Fri, 27 Feb 2009 09:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=erzyA86wbs3jfs79Kez1w7nCDdGAGvV80DzzjCSlBjI=; b=avdDZ0yb5szrULFwESjWpRNh0+y9520N9lXRdifoe3z9ZyYT7d0irsOcARtjwNzKzg mwUwpS937S8jwHp035TJlZ0zFfTcKE22IaieJV0g6pOPlewLkZklq70x3w1Ow60lQHCP SLhVbocYbIMnSFP+7IRxKQMdw2H2D3UHAyB3ADomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bÇxdoVYI67LXeXd4vjJbEPfvRHJqxCh/05Ekiy3ZD4bZ0vx4R7aH9lNZvXG3Te6NeJ sK6jQyHUbn42himKKOqXq8J9UeiBXdLN6Euz7PcIs5uqhtqIipYfRhvcPYuZQE5UJikM HrH2zriMRlRJSpW19MvZb49UuEbmfSf9vflI0Received: by 10.223.103.207 with SMTP id l15mr56028fao.2.1235754171737; Fri, 27 Feb 2009 09:02:51 -0800 (PST) Received: from windows8d787f9 (bzq-79-178-110-17.red.bezeqint.net [79.178.110.17]) by mx.google.com with ESMTPS id 35sm1958341fkt.23.2009.02.27.09.02.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 09:02:51 -0800 (PST) From: "Roni Even" <ron.even.tlv@gmail.com> To: "'Alan Johnston'" <alan@sipstation.com>, "'poplarbird'" <poplarbird@gmail.com> References: <49a72f95.9e03be0a.0caf.ffffe479@mx.google.com> <49A81910.4030604@sipstation.com> In-Reply-To: <49A81910.4030604@sipstation.com> Date: Fri, 27 Feb 2009 19:01:03 +0200 Message-ID: <49a81cbb.23145e0a.25d9.47ef@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmY+ydHLzf8FyQ4SambxRat6YJ/DgAANvGQ Content-Language: en-us X-Mailman-Approved-At: Fri, 27 Feb 2009 11:32:17 -0800 Cc: xcon@ietf.org Subject: Re: [XCON] [Sip] Questions about the status of dual video feature in SIP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing <xcon.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/xcon> List-Post: <mailto:xcon@ietf.org> List-Help: <mailto:xcon-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Feb 2009 17:02:33 -0000 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 (agoyal@lifesize.com) asking about the state of the work. Regards Roni Even -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Friday, February 27, 2009 6:47 PM To: poplarbird Cc: sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [XCON] Cloning: Additional data in the data model Oscar Novo
- Re: [XCON] Cloning: Additional data in the data m… spromano
- Re: [XCON] Cloning: Additional data in the data m… spromano
- Re: [XCON] Cloning: Additional data in the data m… Mary Barnes
- Re: [XCON] Cloning: Additional data in the data m… Oscar Novo
- Re: [XCON] Cloning: Additional data in the data m… Oscar Novo
- Re: [XCON] Cloning: Additional data in the data m… Oscar Novo
- Re: [XCON] Cloning: Additional data in the data m… spromano
- Re: [XCON] Cloning: Additional data in the data m… spromano
- Re: [XCON] Cloning: Additional data in the data m… Oscar Novo
- Re: [XCON] Cloning: Additional data in the data m… ZIA GHIASSI