From xcon-bounces@ietf.org Sun Feb 1 22:16:20 2009 Return-Path: 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 756743A67C1; Sun, 1 Feb 2009 22:16:20 -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 0D7963A67C1 for ; Sun, 1 Feb 2009 22:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 T46NEzclyJYD for ; Sun, 1 Feb 2009 22:16:18 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D5E353A63D2 for ; Sun, 1 Feb 2009 22:16:14 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5610A204A9; Mon, 2 Feb 2009 07:15:54 +0100 (CET) X-AuditID: c1b4fb3c-ad75dbb00000304c-6e-49868f9a80b2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13498520001; Mon, 2 Feb 2009 07:15:54 +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 07:15:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 07:15:52 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se> In-Reply-To: <20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning: Additional data in the data model Thread-Index: AcmDBtMWrva33XwdRPSAj+6decDTzwB9cDQQ References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se> <20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it> From: "Oscar Novo" To: X-OriginalArrivalTime: 02 Feb 2009 06:15:53.0510 (UTC) FILETIME=[B3CFC460:01C984FD] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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' eleme= nt 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 attribut= e, e.g.: 2. information about the conference/sidebar relationship, e.g.: . As to the "parent enforceable" relationship, I would leave it outside of th= e data model. Cheers, Simon Quoting Oscar Novo : > 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Feb 1 22:25:56 2009 Return-Path: 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 A53573A69D6; Sun, 1 Feb 2009 22:25:56 -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 E85573A691D for ; Sun, 1 Feb 2009 22:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124, 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 fhPNlFVyX83b for ; Sun, 1 Feb 2009 22:25:54 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C0AC33A67C1 for ; Sun, 1 Feb 2009 22:25:53 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D1F1D20FC2; Mon, 2 Feb 2009 07:25:33 +0100 (CET) X-AuditID: c1b4fb3e-b0072bb00000429e-eb-498691dd6610 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3665200C4; Mon, 2 Feb 2009 07:25:33 +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, 2 Feb 2009 07:25:33 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 07:25:32 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C474090@esealmw105.eemea.ericsson.se> In-Reply-To: <20090130191939.0fe3fntt4oswk44o@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning method, question Thread-Index: AcmDB1HoCjP0fI1WRXGdCfa0ShVI7AB9mcIw References: <9520E66537CC4941994C518E3E21091C298777@esealmw105.eemea.ericsson.se> <20090130191939.0fe3fntt4oswk44o@webmail.unina.it> From: "Oscar Novo" To: X-OriginalArrivalTime: 02 Feb 2009 06:25:33.0663 (UTC) FILETIME=[0D9C16F0:01C984FF] X-Brightmail-Tracker: AAAAAA== Cc: xcon@ietf.org Subject: Re: [XCON] Cloning method, question X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Maybe would it be good to state that in CCMP? At the moment neither the fra= mework nor CCMP state this information. IMO it would be useful to have it s= omewhere. = Thanks, Oscar = -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it] = Sent: 30. tammikuuta 2009 20:20 To: Oscar Novo Cc: xcon@ietf.org Subject: Re: [XCON] Cloning method, question I think that keeping track of such changes (and hence maintaining coherence= among inter-related conference objects) is part of the conference server's= business logic. If we come to how the clients are notified about changes (= in general), the event package should do the job (not CCMP...). Simon Quoting Oscar Novo : > Hi again, > > If we dedice to support the 'non-independent' cloning method a = > question that arise is how the parent will notify the child about the cha= nges? > Which protocol will do that? CCMP, xcon-event-pachages? > > 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Feb 1 22:36:19 2009 Return-Path: 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 01FBE3A67C1; Sun, 1 Feb 2009 22:36:19 -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 01A6D3A67C1 for ; Sun, 1 Feb 2009 22:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 fwSFHsx6S-zT for ; Sun, 1 Feb 2009 22:36:17 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BF6223A63D2 for ; Sun, 1 Feb 2009 22:36:16 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD1CC204A1; Mon, 2 Feb 2009 07:35:56 +0100 (CET) X-AuditID: c1b4fb3e-b0072bb00000429e-7b-4986944cbdc1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AE753201EA; Mon, 2 Feb 2009 07:35:56 +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 07:35:56 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 07:35:55 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C47409D@esealmw105.eemea.ericsson.se> In-Reply-To: <20090130193648.ssvv4lsa8s0cgow0@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning: Additional data in the data model Thread-Index: AcmDCbdhidgRQAD8SDOr82tk9Z0UuAB9bHGw References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se> <20090130193648.ssvv4lsa8s0cgow0@webmail.unina.it> From: "Oscar Novo" To: X-OriginalArrivalTime: 02 Feb 2009 06:35:56.0308 (UTC) FILETIME=[80BC2D40:01C98500] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Simon, We decide to go for that solution to avoid the (UPA) Unique Particle Attrib= ution constraint as you said. This problem is with version 1.0. The UPA con= strain might be solved with the coming new 1.1 version. We could modified t= he schema once the 1.1 version is released. = Cheers, Oscar -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it] = Sent: 30. tammikuuta 2009 20:37 To: Oscar Novo Cc: xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model Hello again, Oscar. While working on the data model, we realized that the n= ew 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 impo= rt the mentioned schema, and you define further elements, which are the new= ones introduced within XCON. This works fine, thanks to the presence of th= e "any" element: Personally, I would have liked something more explicit, e.g.: ***************************************************************** xmlns:info=3D"urn:ietf:params:xml:ns:conference-info" ***************************************************************************= **** 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 Quoting Oscar Novo : > 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Feb 1 22:51:38 2009 Return-Path: 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 8D48F28C1C7; Sun, 1 Feb 2009 22:51:38 -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 A534728C1C7 for ; Sun, 1 Feb 2009 22:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.093, 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 sSmQ68CQE4z2 for ; Sun, 1 Feb 2009 22:51:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 11AB83A63D2 for ; Sun, 1 Feb 2009 22:51:35 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EF215205AA; Mon, 2 Feb 2009 07:51:14 +0100 (CET) X-AuditID: c1b4fb3c-ae75fbb00000304c-0b-498697e2614b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B4592204A9; Mon, 2 Feb 2009 07:51:14 +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, 2 Feb 2009 07:51:14 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 07:51:13 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C4740B1@esealmw105.eemea.ericsson.se> In-Reply-To: <11e0ee130901310327w4cae7b14ie4019eb05d942d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Cloning: Additional data in the data model Thread-Index: AcmDluhmPYjrwQ74Qu+Z2R2MnbX0jQBaiEWg References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se> <20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it> <11e0ee130901310327w4cae7b14ie4019eb05d942d@mail.gmail.com> From: "Oscar Novo" To: "Mary Barnes" , X-OriginalArrivalTime: 02 Feb 2009 06:51:14.0683 (UTC) FILETIME=[A42114B0:01C98502] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1894384973==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1894384973== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98502.A3D0CE2B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98502.A3D0CE2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, =20 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.=20 =20 Oscar =20 P.S.: unfortunately we all know how corporate web email access works... = :P Enjoy your new mac! :) =20 =20 ________________________________ From: Mary Barnes [mailto:mary.h.barnes@gmail.com]=20 Sent: 31. tammikuuta 2009 13:27 To: spromano@unina.it Cc: Oscar Novo; xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model Oscar and Simon,=20 1. Shouldn't we call it "parent/child" or "mother/daughter" = relationship ;) Obviously, the latter is the pc choice.=20 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, wrote: Hi Oscar, =09 sorry for the late reply. IMHO, we might need in the data model: =09 1. information about the father/son relationship. This might be an = attribute, e.g.: =09 =09 2. information about the conference/sidebar relationship, e.g.: =09 . =09 As to the "parent enforceable" relationship, I would leave it outside = of the data model. =09 Cheers, =09 Simon =09 =09 Quoting Oscar Novo : =09 =09 Hi folks, =09 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. =09 Some elements that could be added are: =09 - 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. =09 It would be nice to know the opinion of the WG whether we want to support entirely this property or not. =09 Cheers, =09 Oscar =09 =09 =09 =09 --=20 _\\|//_ ( 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 =09 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ =09 _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon =09 ------_=_NextPart_001_01C98502.A3D0CE2B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mary,
 
IMO, the 'parent enforceable' (or 'mother = enforceable' :) )=20 is implicit in the 'cascaded-focus' element. If that element is defined = the=20 'parent enforceable' relationship exist, otherwise not.=20
 
Oscar
 
P.S.: unfortunately we all know how corporate = web email=20 access works... :P Enjoy your new mac! :)
 
 
From: Mary Barnes=20 [mailto:mary.h.barnes@gmail.com]
Sent: 31. tammikuuta 2009=20 13:27
To: spromano@unina.it
Cc: Oscar Novo;=20 xcon@ietf.org
Subject: Re: [XCON] Cloning: Additional data in = the data=20 model

Oscar and Simon,

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

I'm also still thinking we need the "independent" info. While the = logic=20 would be handled by the conference server - e.g., can the parent be = deleted?=20  I think the client needs to know this, so that they don't try to = delete a=20 parent and they are aware that when they get any updates, why that's = happening.=20 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=20 (via secure web i/f) is so, so, so, slow.

On Fri, Jan 30, 2009 at 12:16 PM, <spromano@unina.it> = wrote:
Hi=20 Oscar,

sorry for the late reply. IMHO, we might need in the = data=20 model:

1. information about the father/son relationship. This = might be=20 an attribute, e.g.:

<xs:attribute name=3D"fatherEntity"=20 type=3D"xs:anyURI" use=3D"optional"/>

2. information about = the=20 conference/sidebar relationship, e.g.:

<xs:attribute=20 name=3D"sidebarOf" type=3D"xs:anyURI" use=3D"optional"/>.

As = to the=20 "parent enforceable" relationship, I would leave it outside of the = data=20 model.

Cheers,

Simon


Quoting Oscar Novo = <oscar.novo@ericsson.com>:

Hi=20 folks,

In IETF-73 has been a proposal to expand the data = model to=20 support the
cloning method defined in the framework. At the = moment, the=20 data model
supports the cloning method though the = 'cascaded-focus'=20 element which
contains a 'parent' conference URI but it might be = needed=20 to add few
more elements to be align with CCMP.

Some = elements that=20 could be added are:

- An element that contains all the=20 'non-independent' children
conferences
- A policy = attribute/element=20 that indicates the "parent enforceable" of
every element. = However, it=20 would make more sense to add it in a draft
that discusses = conference=20 policies.

It would be nice to know the opinion of the WG = whether we=20 want to
support entirely this property or=20 = not.

Cheers,

Oscar






= --=20
                  =  =20        _\\|//_
        =  =20                  ( O-O=20 )
 =20 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =  =20                Simon Pietro=20 Romano
             Universita' = di=20 Napoli Federico II
              =  =20 Computer Science Department
       Phone: +39 = 081=20 7683823 -- Fax: +39 081 7684219
          =  =20    e-mail: spromano@unina.it

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

_______________________________________________
XCON = mailing=20 list
XCON@ietf.org
https://www.ietf.org/mailman/listinfo/xcon

------_=_NextPart_001_01C98502.A3D0CE2B-- --===============1894384973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon --===============1894384973==-- From xcon-bounces@ietf.org Mon Feb 2 01:11:25 2009 Return-Path: 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 7DA023A6896; Mon, 2 Feb 2009 01:11:25 -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 0DB043A68BF for ; Mon, 2 Feb 2009 01:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.619] 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 lqkQG9jsBvIE for ; Mon, 2 Feb 2009 01:11:23 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 7B3BD3A68A5 for ; Mon, 2 Feb 2009 01:11:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id n129Ax60020302; Mon, 2 Feb 2009 10:10:59 +0100 Received: from 143.225.190.198 ([143.225.190.198]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 02 Feb 2009 10:10:59 +0100 Message-ID: <20090202101059.5v63j5rd9wcw0wog@webmail.unina.it> Date: Mon, 02 Feb 2009 10:10:59 +0100 From: spromano@unina.it To: Oscar Novo References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se> <20090130191605.rx6xh6sj1ck4wcww@webmail.unina.it> <9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se> In-Reply-To: <9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/8938/Mon Feb 2 04:26:52 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="Yes" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org 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 : > 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.: > > > > 2. information about the conference/sidebar relationship, e.g.: > > . > > As to the "parent enforceable" relationship, I would leave it = > outside of the data model. > > Cheers, > > Simon > > > Quoting Oscar Novo : > >> 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 > > < 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Feb 2 01:12:27 2009 Return-Path: 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 AF03F3A6862; Mon, 2 Feb 2009 01:12:27 -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 630783A6862 for ; Mon, 2 Feb 2009 01:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 2rylDKeB3KZ4 for ; Mon, 2 Feb 2009 01:12:25 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 229A23A67E3 for ; Mon, 2 Feb 2009 01:12:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id n129C1CC020613; Mon, 2 Feb 2009 10:12:03 +0100 Received: from 143.225.190.198 ([143.225.190.198]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 02 Feb 2009 10:12:01 +0100 Message-ID: <20090202101201.pworyoxpwgc408co@webmail.unina.it> Date: Mon, 02 Feb 2009 10:12:01 +0100 From: spromano@unina.it To: Oscar Novo References: <9520E66537CC4941994C518E3E21091C298760@esealmw105.eemea.ericsson.se> <20090130193648.ssvv4lsa8s0cgow0@webmail.unina.it> <9520E66537CC4941994C518E3E21091C47409D@esealmw105.eemea.ericsson.se> In-Reply-To: <9520E66537CC4941994C518E3E21091C47409D@esealmw105.eemea.ericsson.se> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/8938/Mon Feb 2 04:26:52 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="Yes" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Agreed ;-) Simon Quoting Oscar Novo : > 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: spromano@unina.it [mailto:spromano@unina.it] > Sent: 30. tammikuuta 2009 20:37 > To: Oscar Novo > Cc: xcon@ietf.org > 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: > > maxOccurs=3D"unbounded"/> > > Personally, I would have liked something more explicit, e.g.: > > ***************************************************************** > > xmlns:info=3D"urn:ietf:params:xml:ns:conference-info" > > schemaLocation=3D"rfc4575DataModel.xsd"/> > > > > > > > > > > > > > > > type=3D"xs:boolean"/> > > > > > > > > type=3D"user-admission-policy-type"/> > > > > > > > > > *************************************************************************= ****** > > 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 > > Quoting Oscar Novo : > >> 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 > > < 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Feb 2 02:43:18 2009 Return-Path: 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 ; 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 ; 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 ; 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, 2 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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-focu= s' 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 fo= cus 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 conf= erence 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 : > 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.: > > > > 2. information about the conference/sidebar relationship, e.g.: > > . > > As to the "parent enforceable" relationship, I would leave it = > outside of the data model. > > Cheers, > > Simon > > > Quoting Oscar Novo : > >> 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 > > < 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon Return-Path: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 =20 > 'cascaded-focus' in RFC4575 states: > > "This element contains a conference URI (different from the main =20 > conference URI) for users that are connected to the main conference =20 > as a result of focus cascading. Though cascading might be implemented through cloning, I don't see a =20 direct link between the "parent/child" relationship and the "main =20 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 =20 cloned objects have to be sidebars. Furthermore, sidebars and cascaded =20 foci do represent different things. Let me expand a bit on this...With =20 the current data model, with sidebars-by-ref you can browse from the =20 main conference to the sidebars; what is missing is, inside a certain =20 sidebar, a means to identify the main conference it belongs to. If I =20 understand correctly, what you are proposing is to use the =20 'cascaded-focus' element in the sidebar conference object to identify =20 the main conference from which the sidebar was stemmed. I think we should go the easy way, i.e. let semantics be represented =20 in the data model, without forcing any specific conceptual =20 association. Stated in simple terms: i) do we need to express a (general) parent/child relationship? If so, =20 let's make it explicit in the data model; ii) do we need to know whether a specified conf object is a sidebar of =20 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 =20 > certain conference is a child of a parent conference; similarly, =20 > with sidebars, I would like to know if a certain conference object =20 > actually represents a sidebar of another conference. The two =20 > mechanisms you mention ('cascaded-focus' and 'sidebars-by-ref') =20 > allow you to "browse" > conference objects in exactly the opposite direction. What is your =20 > feeling about that? > > Cheers, > > Simon > > Quoting Oscar Novo : > >> 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.: >> >> >> >> 2. information about the conference/sidebar relationship, e.g.: >> >> . >> >> As to the "parent enforceable" relationship, I would leave it >> outside of the data model. >> >> Cheers, >> >> Simon >> >> >> Quoting Oscar Novo : >> >>> 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 >> >> <> 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 > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > --=20 _\\|//_ ( 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ Return-Path: 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 ; 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 ; 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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 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 =20 > 'cascaded-focus' in RFC4575 states: > > "This element contains a conference URI (different from the main =20 > conference URI) for users that are connected to the main conference =20 > 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 =20 > certain conference is a child of a parent conference; similarly, =20 > with sidebars, I would like to know if a certain conference object =20 > actually represents a sidebar of another conference. The two =20 > mechanisms you mention ('cascaded-focus' and 'sidebars-by-ref') =20 > allow you to "browse" > conference objects in exactly the opposite direction. What is your =20 > feeling about that? > > Cheers, > > Simon > > Quoting Oscar Novo : > >> Hi Simon, >> >> Thanks for your reply. >> Regarding the new attributes you proposed. I might be wrong but I=20 >> think the father/son relationship is already covered with the=20 >> 'cascaded-focus' element and the conference/sidebar relationship is=20 >> 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=20 >> attribute, e.g.: >> >> >> >> 2. information about the conference/sidebar relationship, e.g.: >> >> . >> >> As to the "parent enforceable" relationship, I would leave it outside = >> of the data model. >> >> Cheers, >> >> Simon >> >> >> Quoting Oscar Novo : >> >>> Hi folks, >>> >>> In IETF-73 has been a proposal to expand the data model to support=20 >>> the cloning method defined in the framework. At the moment, the data = >>> model supports the cloning method though the 'cascaded-focus'=20 >>> element which contains a 'parent' conference URI but it might be=20 >>> 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=20 >>> conferences >>> - A policy attribute/element that indicates the "parent enforceable" >>> of every element. However, it would make more sense to add it in a=20 >>> draft that discusses conference policies. >>> >>> It would be nice to know the opinion of the WG whether we want to=20 >>> 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 >> >> <> 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 > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > --=20 _\\|//_ ( 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ Return-Path: 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 ; 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 ; 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 ; 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+ShmW1vVgNqKioQApEqeAAA2w2qA= 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> From: "Mary Barnes" To: "Oscar Novo" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. =20 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.=20 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.=20 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.=20 Regards, Mary.=20 -----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=20 -----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 =20 > 'cascaded-focus' in RFC4575 states: > > "This element contains a conference URI (different from the main =20 > conference URI) for users that are connected to the main conference =20 > 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 =20 > certain conference is a child of a parent conference; similarly, =20 > with sidebars, I would like to know if a certain conference object =20 > actually represents a sidebar of another conference. The two =20 > mechanisms you mention ('cascaded-focus' and 'sidebars-by-ref') =20 > allow you to "browse" > conference objects in exactly the opposite direction. What is your =20 > feeling about that? > > Cheers, > > Simon > > Quoting Oscar Novo : > >> Hi Simon, >> >> Thanks for your reply. >> Regarding the new attributes you proposed. I might be wrong but I=20 >> think the father/son relationship is already covered with the=20 >> 'cascaded-focus' element and the conference/sidebar relationship is=20 >> 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=20 >> attribute, e.g.: >> >> >> >> 2. information about the conference/sidebar relationship, e.g.: >> >> . >> >> As to the "parent enforceable" relationship, I would leave it outside = >> of the data model. >> >> Cheers, >> >> Simon >> >> >> Quoting Oscar Novo : >> >>> Hi folks, >>> >>> In IETF-73 has been a proposal to expand the data model to support=20 >>> 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=20 >>> 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=20 >>> conferences >>> - A policy attribute/element that indicates the "parent enforceable" >>> of every element. However, it would make more sense to add it in a=20 >>> draft that discusses conference policies. >>> >>> It would be nice to know the opinion of the WG whether we want to=20 >>> 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 >> >> <> 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 > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > --=20 _\\|//_ ( 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon Return-Path: 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 ; 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 ; 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 ; 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" To: "Mary Barnes" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 08:11:51 -0000 Mary, Thanks for your comment. Oscar=20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 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. =20 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.=20 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.=20 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.=20 Regards, Mary.=20 -----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=20 -----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 =20 > 'cascaded-focus' in RFC4575 states: > > "This element contains a conference URI (different from the main =20 > conference URI) for users that are connected to the main conference =20 > 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 =20 > certain conference is a child of a parent conference; similarly, =20 > with sidebars, I would like to know if a certain conference object =20 > actually represents a sidebar of another conference. The two =20 > mechanisms you mention ('cascaded-focus' and 'sidebars-by-ref') =20 > allow you to "browse" > conference objects in exactly the opposite direction. What is your =20 > feeling about that? > > Cheers, > > Simon > > Quoting Oscar Novo : > >> Hi Simon, >> >> Thanks for your reply. >> Regarding the new attributes you proposed. I might be wrong but I=20 >> think the father/son relationship is already covered with the=20 >> 'cascaded-focus' element and the conference/sidebar relationship is=20 >> 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=20 >> attribute, e.g.: >> >> >> >> 2. information about the conference/sidebar relationship, e.g.: >> >> . >> >> As to the "parent enforceable" relationship, I would leave it outside = >> of the data model. >> >> Cheers, >> >> Simon >> >> >> Quoting Oscar Novo : >> >>> Hi folks, >>> >>> In IETF-73 has been a proposal to expand the data model to support=20 >>> 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=20 >>> 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=20 >>> conferences >>> - A policy attribute/element that indicates the "parent enforceable" >>> of every element. However, it would make more sense to add it in a=20 >>> draft that discusses conference policies. >>> >>> It would be nice to know the opinion of the WG whether we want to=20 >>> 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 >> >> <> 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 > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > --=20 _\\|//_ ( 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon Return-Path: 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: 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" To: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 09 Feb 2009 15:00:39 -0800 Cc: Cullen Jennings , gen-art@ietf.org, xcon-chairs@tools.ietf.org, xcon@ietf.org, Jon Peterson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ).=20 Please resolve these comments along with any other Last Call comments you may receive.=20 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)=20 Summary: Ready with a few minor nits. Major issues: None Minor issues:=20 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:=20 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: 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 ; 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 ; 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 ; 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" To: , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.=20 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."=20 [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?=20 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.=20 8.2.3 Operations Request [ON] What does the N/A means in the HTTP examples of sidebarRequest?=20 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.=20 =20 8.3.3.3. Change Operation Response =20 "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.=20 [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. =20 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.=20 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: change success xcon:confxyz987@example.com userC-confxyz987 58943 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 ' attribute' to ' 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 CCMP comments

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=3D"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-- Return-Path: 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 ; 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 ; 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 ; Fri, 27 Feb 2009 09:02:31 -0800 (PST) Received: by fxm8 with SMTP id 8so597412fxm.13 for ; 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+7IRxKQMdw2H2D3UHAyB3A= DomainKey-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=c7xdoVYI67LXeXd4vjJbEPfvRHJqxCh/05Ekiy3ZD4bZ0vx4R7aH9lNZvXG3Te6NeJ sK6jQyHUbn42himKKOqXq8J9UeiBXdLN6Euz7PcIs5uqhtqIipYfRhvcPYuZQE5UJikM HrH2zriMRlRJSpW19MvZb49UuEbmfSf9vflI0= Received: 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" To: "'Alan Johnston'" , "'poplarbird'" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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