From duddy@avaya.com Wed Feb 3 03:01:48 2010 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 E449228C0F7 for ; Wed, 3 Feb 2010 03:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 cOdYiRON63mw for ; Wed, 3 Feb 2010 03:01:48 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 646443A6C0D for ; Wed, 3 Feb 2010 03:01:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,397,1262581200"; d="scan'208";a="175070785" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Feb 2010 06:02:14 -0500 X-IronPort-AV: E=Sophos;i="4.49,397,1262581200"; d="scan'208";a="442037256" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Feb 2010 06:02:13 -0500 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: Wed, 3 Feb 2010 11:04:10 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D1C01@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYAAHYHPAAlFXiVA= References: <4B523F84.4000407@gmail.com> From: "Duddy, Sean (Sean)" To: Subject: [XCON] Comments on draft-ietf-xcon-ccmp-05 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: Wed, 03 Feb 2010 11:01:49 -0000 Hi All, There is a contradiction in section :- 7.7. Alice adds a new user to the conference The text preceeding the call flow indicates that the response should contain the confUserID of the newly added participant. However the example shows the confUserID is constant for the transaction i.e. 'Alice'. In my opinion, the text is wrong and needs to change. On a genral note, should we have CCMP examples in both the ccmp draft and in the new examples draft? Personally I think the examples should be in one doc only. Sean From oscar.novo@ericsson.com Wed Feb 3 07:10:34 2010 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 925EE3A6C36 for ; Wed, 3 Feb 2010 07:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PY0-dxKnPGUp for ; Wed, 3 Feb 2010 07:10:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9C2F43A6B14 for ; Wed, 3 Feb 2010 07:10:31 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-25-4b69920f7589 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B6.82.02429.F02996B4; Wed, 3 Feb 2010 16:11:12 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 3 Feb 2010 16:11:11 +0100 From: Oscar Novo To: Richard Barnes Date: Wed, 3 Feb 2010 16:11:10 +0100 Thread-Topic: [XCON] Review of draft-ietf-xcon-common-data-model Thread-Index: AcoeriuffWHw5kJ4Qw6As53Iwfqp6SFWqM2w Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC2E7@ESESSCMS0353.eemea.ericsson.se> References: <4A88689A.2050006@bbn.com> In-Reply-To: <4A88689A.2050006@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "xcon@ietf.org" Subject: Re: [XCON] Review of draft-ietf-xcon-common-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: Wed, 03 Feb 2010 15:10:34 -0000 Hi Richard, I'm sorry to reply to your comments so late. Some comments inline. Cheers, Oscar=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: 16. elokuuta 2009 23:14 To: xcon@ietf.org Subject: [XCON] Review of draft-ietf-xcon-common-data-model Hi all, In my effort to get up to speed on XCON, I'm in the process of reviewing th= e active working group drafts (in addition to the other relevant background= ). My review of draft-ietf-xcon-common-data-model is below. --Richard ----- Draft: draft-ietf-xcon-common-data-model-13 Reviewer: Richard Barnes Review Date: 13 Mar 07 General Comments: 1. The major challenge I had with this document there doesn't seem to be a = clear separation in some cases between what the document describes, and wha= t actions are implied. I'll call out specific instances below, but in futu= re revisions, I would encourage the authors to focus describing clearly wha= t the state of the conference is that this object describes, and separately= , what actions this state requires or allows. Specific Comments: Section 1, Paragraph 1 The phrase "... using an Extensible Markup Language (XML)-based." does not= parse. [ON] I'm sorry I think I don't understand this comment. That's a simple tex= t. What do you mean by 'does not parse'? Section 1, Paragraph 3 s/and specifies who/and specifies by whom/ [ON] Now, it's fixed Section 3.3.1, ABNF It seems like a lot of the ABNF for the SIP URI (RFC3261, page 222) could b= e re-usable here. E.g., you could just say XCON-URI =3D "xcon:" [ userinfo ] hostport This would align the sets of = allowed characters in what is now the conf-object-id, which could make pars= ing easier. It would also add back in the "password" field (within userinf= o), which could be useful when these URIs are used to access XCON conferenc= es via CCMP (you would however, have to REQUIRE that the password be the sa= me as the ). [ON] The XCON-URI is a top level identifier. It provides a binding with the= rest of the conference object identifiers. I think linking the password to= the XCON-URI identifier is not a good idea since it creates constraints to= the conference. For instance, if later you need to modify the password of = the conference you might have to modify the XCON-URI of the conference and = in some systems that might not be the best idea.=20 Section 4.2.1 It seems like there should be some structure to the element, e.g= ., using the language tags from RFC1766. [ON] I have included a structure to the element following the RF= C5646 and the IANA docs. RFC5646 replaces RFC1766.=20 Section 4.2.6 This section specifies the meaning of this element if it is present and set= to true, but not what it means for it to be present and false, or absent. = Is the default for sidebars to be disallowed, confirmed by a moderator, et= c.? [ON] I have added the following text to the definition: "If absent, or set = to FALSE, the conference can not create sidebar conferences." Section 4.2.9, bullet This section says that the elem= ent specifies when mixing starts "before"=20 the conference starts. Should this be "relative to", or is it not allowed = for mixing to start after the conference starts? [ON] The Conference media mixing is used to apply all the properties of the= conference (the properties defined in the data model), for instance, add s= ome standard algorithms in the conference, add floor control properties, de= fine moderator, etc... I would say, it does not have too much sense to star= t a conference and later the mixing.=20 Section 4.2.9, bullet It's a little bit = confusing that this element ends in -offset but isn't an offset. Does this= interact with the requiredParticipant attribute of the = element? E.g., can this element indicate that a privileged participant sh= ould be denied an extension to the mixing time? [ON] Yes, both of the elements are linked together but it's up to the confe= rence policy how they interact in the conference.=20 Section 4.2.13, bullet This section specifies what the "M= oderator-controlled" and "FCFS"=20 policies mean (although it's not clear to me what "a first-come-first-serve= d" algorithm is when comes to media), but doesn't define what the "Automati= c" algorithm means. [ON] It refers to the scheduling policy in the media part. The "Automatic" = value means the mixer choose the best scheduling policy for the conference.= I've tried to clarify that point a bit better in the draft. =20 Section 4.2.13, bullet It's really unclear what this element means. Are the sub-elements of the "= controls" element describing controls that are available to a user?=20 Constraints on how the current media streams are handled? I.e., does true tell the conference server to stop sending audio, or does it= tell a client to show a "mute" control to the user? [ON] Those controls are linked to the media stream in the server and they'r= e constraints of how the media is handle in the server part. So, a 'mute' c= ontrol for a user means that the server stops sending audio to that user. = =20 Section 4.2.13, bullet Why are these controls necessary? Are there systems that are doing video l= ayout on the server? If not, then isn't it just a client UI issue? [ON] From draft "draft-ietf-mediactrl-mixer-control-package": "The element describe the video presentation layout configuration for pa= rticipants providing a video input stream to the conference. This element = allows multiple video layouts to be specified so that the MS automatically = changes layout depending on the number of video-enabled participants." Section 4.6.2 For clarity, it might be helpful here (and in the Security Considerations) to say that these elements specify only that the clients mu= st authenticate to the server, using a mechanism of the server's choosing -= - the specific mechanism(s) to be used are determined by individual servers= for individual CSPs, and are beyond the scope of this document. [ON] I've modified the text accordingly Section 4.6.5 Why does the "entity" attribute have to be unique in the scope of the confe= rencing system, rather than within the scope of the conference? At first b= lush, it might seem like this is necessary for CCMP, but in that case, ther= e is always a conference-ID present to disambiguate. [ON]yep, right. That's a mistake.=20 Section 4.6.5.3 s/provides anonymity/specifies what level of anonymity the server should pr= ovide/ [ON] right, now it's fixed Section 4.6.5.7 s/boolean action/boolean value/ [ON] fixed, thanks Section 4.6.5.* It seems like there's an element missing, something like . and correspond to the "dial-ou= t", and "refer" values for "method" above; what about "dial-in"? [ON] I think I don't understand very well the propose of your element . If you want to determined who can join the conf= erence there is already an element in the conference for that, . The element is a "dial-in" element too. Anot= her "dial-in" element could be . Section 4.6.5.10, paragraph 3 Is this phrase correct? "... a floor that joins the participant in the conf= erence"? [ON] I have changed that phrase: "The element refers to the floor a= ssigned to a certain participant in the conference" Section 8.1 See above comment on Section 4.6.2 [ON] I've modified the text accordingly in this section too. Section 8.2 This section should be rewritten to be a little less hand-wavy. The key po= ints are (1) conference information can be sensitive, so (2) protocols that= transmit conference object need to be able to confidentiality-protect them= . Couple of sentences describing the risks, then one sentence saying the "= Protocols that transmit conference objects (or fragments thereof) MUST be a= ble to provide confidentiality protection to them." [ON] I've re-written a bit this section and tried to be more specific in th= is section Section 8.3 Since we're mostly talking about an object as it resides on the conference = server, most of the integrity are related to authentication and access cont= rol. So this section could probably be deleted in favor of changing the ti= tle of 8.1 to "Authentication, Access Control, & Integrity". The only addi= tion that might be necessary is to ensure that protocols that carry these o= bjects over the wire provide them with integrity protection in order to ens= ure the integrity of the management process; essentially the confidentialit= y sentence above, s/confidentiality/integrity/. [ON] I've removed this section and included the information in the authenti= cation section. _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From oscar.novo@ericsson.com Wed Feb 3 07:10:39 2010 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 E42013A6C36 for ; Wed, 3 Feb 2010 07:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 h61e5T4utdG2 for ; Wed, 3 Feb 2010 07:10:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 914263A6867 for ; Wed, 3 Feb 2010 07:10:36 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-3b-4b699217a518 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BA.82.02429.712996B4; Wed, 3 Feb 2010 16:11:19 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 3 Feb 2010 16:11:18 +0100 From: Oscar Novo To: "Duddy, Sean (Sean)" , "xcon@ietf.org" Date: Wed, 3 Feb 2010 16:11:16 +0100 Thread-Topic: [XCON] Comments on draft-ietf-xcon-common-data-model-14 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYAJUBYVQ Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC2E8@ESESSCMS0353.eemea.ericsson.se> References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A466F@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A466F@306900ANEX2.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] Comments on draft-ietf-xcon-common-data-model-14 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: Wed, 03 Feb 2010 15:10:39 -0000 Hi Sean, In this case the '*' is right. Elements with a '*' are extensions in the da= ta model.=20 Cheers, Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Dud= dy, Sean (Sean) Sent: 22. tammikuuta 2010 14:18 To: xcon@ietf.org Subject: [XCON] Comments on draft-ietf-xcon-common-data-model-14 Minor change: In section 4, there is an '*' after the element indicatin= g that this element has been defined in rfc4575.=20 This '*' should be removed because is a new extension def= ined in this model... Sean _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From oscar.novo@ericsson.com Wed Feb 3 07:10:48 2010 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 6EF943A6C46 for ; Wed, 3 Feb 2010 07:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 j3nQTKXAeSo6 for ; Wed, 3 Feb 2010 07:10:47 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 056233A6C49 for ; Wed, 3 Feb 2010 07:10:43 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-20-4b69921dfc50 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 34.F4.31641.D12996B4; Wed, 3 Feb 2010 16:11:25 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 3 Feb 2010 16:11:24 +0100 From: Oscar Novo To: "Duddy, Sean (Sean)" , "xcon@ietf.org" Date: Wed, 3 Feb 2010 16:11:23 +0100 Thread-Topic: [XCON] Comments on draft-ietf-xcon-common-data-model-14 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYAAHYHPAAk0YKpA= Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC2E9@ESESSCMS0353.eemea.ericsson.se> References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A46F5@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A46F5@306900ANEX2.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] Comments on draft-ietf-xcon-common-data-model-14 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: Wed, 03 Feb 2010 15:10:48 -0000 Hi, Thanks for the note. I'll fix it in the next version. Oscar=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Dud= dy, Sean (Sean) Sent: 22. tammikuuta 2010 17:48 To: xcon@ietf.org Subject: [XCON] Comments on draft-ietf-xcon-common-data-model-14 Hi, =09 The elements Have the wrong type, they should have type "xs:anyURI" Sean _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From oscar.novo@ericsson.com Wed Feb 3 07:10:53 2010 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 99A1A3A6C51 for ; Wed, 3 Feb 2010 07:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VaaDFkO9xHHO for ; Wed, 3 Feb 2010 07:10:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 87E783A6C4C for ; Wed, 3 Feb 2010 07:10:48 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-56-4b699221af93 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CE.82.02429.122996B4; Wed, 3 Feb 2010 16:11:29 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Feb 2010 16:11:28 +0100 From: Oscar Novo To: "Duddy, Sean (Sean)" , "xcon@ietf.org" Date: Wed, 3 Feb 2010 16:11:27 +0100 Thread-Topic: draft-ietf-xcon-common-data-model-14 Thread-Index: AcqfSij3aQa6iQTxQq+jLBhs8rRvvgFciftg Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC2EA@ESESSCMS0353.eemea.ericsson.se> References: <4408C6EC74CC3D42824FD68FDA8E8F71010D14E6@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010D14E6@306900ANEX2.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2EAESESSCMS0353e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] draft-ietf-xcon-common-data-model-14 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: Wed, 03 Feb 2010 15:10:53 -0000 --_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2EAESESSCMS0353e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sean, True, the field should be defined as multiple password. I'll change that in= the following version of the draft. The propose to have different passwords in the flexibility to have differen= t set of users with different credentials. So, the conference server can re= strict access to a set of users by just removing the credentials from the s= erver. I think the extension of the element is not really needed since= the limitations of the credentials can be done using the same roles (you m= ight want to restrict access to the group of participants A but not the gro= up of participants B). Regards, Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Dud= dy, Sean (Sean) Sent: 27. tammikuuta 2010 14:14 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model-14 Hi all, The new password field in draft-ietf-xcon-common-data-model-14 is defi= ned as follows:- In section 4.2.10, it states that this field contain password(s). What woul= d be the usecase for multiple passcodes on the same URI? If it is a valid use case then the xsd type for this should xs::list. Does the purpose field defined in rfc4575 need to be extended to indicate t= he type of URI i.e. moderator,particpant etc? Or how would a client that just created a conference distinguish between th= e URIs? Regards Sean --_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2EAESESSCMS0353e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sean,
 
True, the field should be defined as multiple pass= word.=20 I'll change that in the following version of the draft.
The propose to have different passwords in the fle= xibility=20 to have different set of users with different credentials. So, the conferen= ce=20 server can restrict access to a set of users by just removing the=20 credentials from the server.
 <= /DIV>
I think the extension of the <conf-uris> ele= ment is=20 not really needed since the limitations of the credentials can be done usin= g the=20 same roles (you might want to restrict access to the group of participants = A but=20 not the group of participants B).
 
Regards,
 
Oscar

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean=20 (Sean)
Sent: 27. tammikuuta 2010 14:14
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-common-data-model-14

Hi=20 all,
 &nb= sp; =20 The new password field in  draft-ietf-xcon-common-data-model-14 i= s=20 defined as follows:-
 
    <xs:element=20 name=3D"conference-password" type=3D"xs:string"/>
 
In sectio= n 4.2.10,=20 it states that this field contain password(s). What would be the usecase fo= r=20 multiple passcodes on the same URI?
If it is = a valid use=20 case then the xsd type for this should xs::list.
 
Does the = purpose=20 field defined in rfc4575 need to be extended to indicate the type of URI i.= e.=20 moderator,particpant etc?
Or how wo= uld a=20 client that just created a conference distinguish between the=20 URIs?
 
Regards
Sean
--_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2EAESESSCMS0353e_-- From oscar.novo@ericsson.com Wed Feb 3 07:10:55 2010 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 BA22C3A67B2 for ; Wed, 3 Feb 2010 07:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cUbMO23dj0fj for ; Wed, 3 Feb 2010 07:10:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E67573A6C50 for ; Wed, 3 Feb 2010 07:10:51 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-3a-4b6992265dcb Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 88.F4.31641.622996B4; Wed, 3 Feb 2010 16:11:34 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 3 Feb 2010 16:11:34 +0100 From: Oscar Novo To: "spromano@unina.it" Date: Wed, 3 Feb 2010 16:11:32 +0100 Thread-Topic: Additional Data in the Data Model Thread-Index: Acqfg/V0G9JxSVydTEaYRSq5rO0sdAFOi4hw Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC2EC@ESESSCMS0353.eemea.ericsson.se> References: <9520E66537CC4941994C518E3E21091CC4BB3F@esealmw105.eemea.ericsson.se> <20100127200722.tf0t7zk4g0o8ss4k@webmail.unina.it> In-Reply-To: <20100127200722.tf0t7zk4g0o8ss4k@webmail.unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "xcon@ietf.org" , Mary Barnes Subject: Re: [XCON] 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: Wed, 03 Feb 2010 15:10:56 -0000 Hi Simon, Yes, that's right. I'll changed that in the next version. Cheers, Oscar=20 -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 27. tammikuuta 2010 21:07 To: Oscar Novo Cc: xcon@ietf.org; Mary Barnes Subject: Re: Additional Data in the Data Model Hi Oscar, it looks like the definition of the mentioned elements contains a mismatche= d "unsignedLong" type. Shouldn't this be of type "anyUri", as per the "enti= ty" attribute of the conference object? ***** BEGIN excerpt from draft ************ ***** END excerpt from draft *************** Cheers, Simon Quoting Oscar Novo : > Hi guys! > > As per discussion in this mailing list and in the last IETF-74=20 > meeting, the authors of the data model are proposing to add the=20 > following elements to the data model to explicit express cloning in the d= ocument. > The elements we're planning to add are: > > - cloning-parent: When this element is present, it indicates that the=20 > conference object is a child of a parent conference. This element=20 > contains the conference object Identifier (XCON-URI) (different from=20 > the main XCON-URI) of the parent. > - sidebar-parent; When this element is present, it indicates that the=20 > conference object represents a sidebar of another conference. This=20 > element contains the conference object Identifier (XCON-URI)=20 > (different from the main XCON-URI) of the parent. > > If nobody oppose to this modifications, we'll submit a new version of=20 > the document in brief. > > Of course, any feedback to the document or to the previous=20 > modifications are always very welcome. :) > > Cheers, > > Oscar > --=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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From oscar.novo@ericsson.com Wed Feb 3 07:12:59 2010 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 A83EA3A6A19 for ; Wed, 3 Feb 2010 07:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001] 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 nxVJj+LgOzan for ; Wed, 3 Feb 2010 07:12:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BF2DA3A6C59 for ; Wed, 3 Feb 2010 07:12:44 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-e5-4b699295f699 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B2.55.31641.592996B4; Wed, 3 Feb 2010 16:13:26 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 3 Feb 2010 16:13:26 +0100 From: Oscar Novo To: "xcon@ietf.org" Date: Wed, 3 Feb 2010 16:13:23 +0100 Thread-Topic: New version of the draft-ietf-xcon-common-data-model Thread-Index: Acqk421moXIY443fSWm1O4Ez9M0HmA== Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC2F3@ESESSCMS0353.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2F3ESESSCMS0353e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [XCON] New version of the draft-ietf-xcon-common-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: Wed, 03 Feb 2010 15:12:59 -0000 --_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2F3ESESSCMS0353e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have created another version of the drafts with all the comments I got in= the last months. You can fetch it from: http://users.piuha.net/eoscdia/draft-ietf-xcon-common-data-model-15.txt I haven't submitted yet. I'll do it next week or so. So, you can get an ide= a of the future version of the draft and make comments to the new version b= efore to submit it. Cheers, Oscar [http://www.ericsson.com/shared/images/Email_line.gif] OSCAR NOVO Scientific Engineer Ericsson Finland, Oy L M Ericsson Ab Hirsalantie 11 02420 Jorvas, Finland www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2F3ESESSCMS0353e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have created another version of the drafts= =20 with all the comments I got in the la= st=20 months. You can fetch it from:

http://users.piuha.net/eoscdia/draft-ietf-xcon-common-data-model-1= 5.txt

I haven't submitted yet. I'll do it next week or so. So, you can g= et an=20 idea of the future version of the draft and make comments to the new <= SPAN=20 class=3D420391115-03022010>version before to submit it.=20

Cheers,
 
Oscar


3Dline

OSCAR NOVO=20
Scientifi= c=20 Engineer


Ericsson Finl= and, Oy=20 L M Ericsson Ab
Hirsalantie 11
02420 Jorvas, Finland
www.ericsson.= com=20



3DEricsson=20






This=20 Communication is Confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 
--_000_209F0863F938D249AFDC024EC4C9E3E20C077CC2F3ESESSCMS0353e_-- From duddy@avaya.com Wed Feb 3 10:59:38 2010 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 628A528C1CB for ; Wed, 3 Feb 2010 10:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5-wEL+ODcFDa for ; Wed, 3 Feb 2010 10:59:37 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id F2C2628C1D8 for ; Wed, 3 Feb 2010 10:36:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,399,1262581200"; d="scan'208,217";a="175142370" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Feb 2010 13:37:07 -0500 X-IronPort-AV: E=Sophos;i="4.49,399,1262581200"; d="scan'208,217";a="427868260" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Feb 2010 13:36:36 -0500 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_01CAA4FF.CD7741E2" Date: Wed, 3 Feb 2010 18:36:10 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D1D12@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-common-data-model-14 Thread-Index: Acqk/8F7t+dA/3/ZRTWeY4FehgoJFA== From: "Duddy, Sean (Sean)" To: Subject: [XCON] draft-ietf-xcon-common-data-model-14 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: Wed, 03 Feb 2010 18:59:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA4FF.CD7741E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am wondering should we include a new element in the element to indicate if the conference as a whole is muted?=20 I think this conference attribute should be in the standard as opposed to an extension... =20 Sean ------_=_NextPart_001_01CAA4FF.CD7741E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
    I=20 am wondering should we include a new element in the=20 <conference-state>  element to indicate if the conference as = a whole=20 is muted?
I = think this=20 conference attribute should be in the standard as opposed to an=20 extension...
 
Sean
------_=_NextPart_001_01CAA4FF.CD7741E2-- From oscar.novo@ericsson.com Thu Feb 4 03:29:09 2010 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 3F69B3A6BCF for ; Thu, 4 Feb 2010 03:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 m1GtBI7xZ20a for ; Thu, 4 Feb 2010 03:29:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 124763A6BFA for ; Thu, 4 Feb 2010 03:29:07 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-f6-4b6aafb0e088 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 33.D5.31641.0BFAA6B4; Thu, 4 Feb 2010 12:29:52 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 4 Feb 2010 12:29:52 +0100 From: Oscar Novo To: "Duddy, Sean (Sean)" , "xcon@ietf.org" Date: Thu, 4 Feb 2010 12:29:50 +0100 Thread-Topic: draft-ietf-xcon-common-data-model-14 Thread-Index: Acqk/8F7t+dA/3/ZRTWeY4FehgoJFAAjXvBg Message-ID: <209F0863F938D249AFDC024EC4C9E3E20C077CC768@ESESSCMS0353.eemea.ericsson.se> References: <4408C6EC74CC3D42824FD68FDA8E8F71010D1D12@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010D1D12@306900ANEX2.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_209F0863F938D249AFDC024EC4C9E3E20C077CC768ESESSCMS0353e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] draft-ietf-xcon-common-data-model-14 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, 04 Feb 2010 11:29:09 -0000 --_000_209F0863F938D249AFDC024EC4C9E3E20C077CC768ESESSCMS0353e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sean, That's already implemented in using the element from - Cheers, Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Dud= dy, Sean (Sean) Sent: 3. helmikuuta 2010 20:36 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model-14 Hi, I am wondering should we include a new element in the element to indicate if the conference as a whole is muted? I think this conference attribute should be in the standard as opposed to a= n extension... Sean --_000_209F0863F938D249AFDC024EC4C9E3E20C077CC768ESESSCMS0353e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sean,
 
That's already implemented in using the <mute&g= t;=20 element from <available-media>-<controls>
 
Cheers,
 
Oscar

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean=20 (Sean)
Sent: 3. helmikuuta 2010 20:36
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-common-data-model-14

Hi,
    I=20 am wondering should we include a new element in the=20 <conference-state>  element to indicate if the conference as a w= hole=20 is muted?
I think t= his=20 conference attribute should be in the standard as opposed to an=20 extension...
 
Sean
--_000_209F0863F938D249AFDC024EC4C9E3E20C077CC768ESESSCMS0353e_-- From duddy@avaya.com Thu Feb 4 03:43:59 2010 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 B00E83A6BFA for ; Thu, 4 Feb 2010 03:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BTqGKtpOnZEf for ; Thu, 4 Feb 2010 03:43:58 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id A51233A6C23 for ; Thu, 4 Feb 2010 03:43:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,404,1262581200"; d="scan'208,217";a="2355811" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 04 Feb 2010 06:44:44 -0500 X-IronPort-AV: E=Sophos;i="4.49,404,1262581200"; d="scan'208,217";a="428109223" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Feb 2010 06:44:08 -0500 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_01CAA58F.5983A31C" Date: Thu, 4 Feb 2010 11:43:04 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D1DCF@306900ANEX2.global.avaya.com> In-Reply-To: <209F0863F938D249AFDC024EC4C9E3E20C077CC768@ESESSCMS0353.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-common-data-model-14 Thread-Index: Acqk/8F7t+dA/3/ZRTWeY4FehgoJFAAjXvBgAAB7YQA= References: <4408C6EC74CC3D42824FD68FDA8E8F71010D1D12@306900ANEX2.global.avaya.com> <209F0863F938D249AFDC024EC4C9E3E20C077CC768@ESESSCMS0353.eemea.ericsson.se> From: "Duddy, Sean (Sean)" To: "Oscar Novo" , Subject: Re: [XCON] draft-ietf-xcon-common-data-model-14 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, 04 Feb 2010 11:43:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA58F.5983A31C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I over looked that element. =20 Thanks Oscar ________________________________ From: Oscar Novo [mailto:oscar.novo@ericsson.com]=20 Sent: 04 February 2010 11:30 To: Duddy, Sean (Sean); xcon@ietf.org Subject: RE: draft-ietf-xcon-common-data-model-14 Hi Sean, =20 That's already implemented in using the element from - =20 Cheers, =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean (Sean) Sent: 3. helmikuuta 2010 20:36 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model-14 Hi, I am wondering should we include a new element in the element to indicate if the conference as a whole is muted?=20 I think this conference attribute should be in the standard as opposed to an extension... =20 Sean ------_=_NextPart_001_01CAA58F.5983A31C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I over looked that element.
 
Thanks Oscar

From: Oscar Novo=20 [mailto:oscar.novo@ericsson.com]
Sent: 04 February 2010=20 11:30
To: Duddy, Sean (Sean); xcon@ietf.org
Subject: = RE:=20 draft-ietf-xcon-common-data-model-14

Hi Sean,
 
That's already implemented in using the = <mute>=20 element from = <available-media>-<controls>
 
Cheers,
 
Oscar

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean=20 (Sean)
Sent: 3. helmikuuta 2010 20:36
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-common-data-model-14

Hi,
    I=20 am wondering should we include a new element in the=20 <conference-state>  element to indicate if the conference as = a whole=20 is muted?
I = think this=20 conference attribute should be in the standard as opposed to an=20 extension...
 
Sean
------_=_NextPart_001_01CAA58F.5983A31C-- From duddy@avaya.com Thu Feb 4 08:57:44 2010 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 99DD628C166 for ; Thu, 4 Feb 2010 08:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Z7coNVtx+KMl for ; Thu, 4 Feb 2010 08:57:43 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A92E428C16A for ; Thu, 4 Feb 2010 08:57:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,405,1262581200"; d="scan'208";a="203778181" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Feb 2010 11:58:30 -0500 X-IronPort-AV: E=Sophos;i="4.49,405,1262581200"; d="scan'208";a="428234220" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Feb 2010 11:57:49 -0500 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: Thu, 4 Feb 2010 16:56:44 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D1EA1@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYAAHYHPAAlFXiVAAPiwxoA== References: <4B523F84.4000407@gmail.com> From: "Duddy, Sean (Sean)" To: Subject: [XCON] Comments on draft-ietf-xcon-ccmp-05 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, 04 Feb 2010 16:57:44 -0000 Hi All, I think we need a response code for requests that contain valid xml but certain elements/value(s) are incorrect or are simply not supported by the CCMP server implementation.=20 Maybe a response code of notSupported or something like that? On a previous email I outlined also that we are missing an ObjectAlreadyExists response code. =09 On a separate issue, do you think the CCMP requests should have the ability to store ANYs also? i.e. adding it to ccmp-request-message-type? I don't have a use case for it now but I think there is no harm having the possibility to allow clients specify custom parameters to operations.=20 Also it might be an idea to facilitate the possibility of specifying new requests. The CCMP xsd could expose another=20 Request/Response pair to faciliate this e.g. Sean From mary.ietf.barnes@gmail.com Fri Feb 5 08:51:17 2010 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 1B3C83A687B for ; Fri, 5 Feb 2010 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zbyp1avD2q6N for ; Fri, 5 Feb 2010 08:51:10 -0800 (PST) Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id 670273A687E for ; Fri, 5 Feb 2010 08:51:10 -0800 (PST) Received: by iwn14 with SMTP id 14so4243699iwn.17 for ; Fri, 05 Feb 2010 08:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7h4SHNSNZSi5M+Bwx1ArLRInC/SC50tA6p67InhQkWI=; b=fS2mEOD1PrkoX8pk6aoHsK4tz4LBRjB+NBewnSFS6vpU59jWJP9fsGkEN9UTmJbHuX LpXcERsCp4BeUAhJGKq3pfS0j74jBrK6/yq9dBYtoxUFgZpTypk8BNLXzoe+9P7wCeiA uun/UwTy1h1k/D4n52u65oK/wAwaq4sJiUaBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aXWnSfWStcCVateRLpK513pHz35peB4R7v1/9wYRnnhVjY5K2mbVHJgNzJ5XRJGTcs bTQ+gLRvn+qXofKoxz6jBanClGmJ4Q7YkbghxFuakwdhXsRddWSMig+PAf+QupQaVlIx Qp8TrGM7S7nyn8lGk3NLLZJotIgfXkJg0xbfQ= MIME-Version: 1.0 Received: by 10.231.146.8 with SMTP id f8mr172581ibv.58.1265388716909; Fri, 05 Feb 2010 08:51:56 -0800 (PST) In-Reply-To: <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com> <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> Date: Fri, 5 Feb 2010 10:51:56 -0600 Message-ID: <184b5e71002050851we7d5bbeme3cc5be326dcff52@mail.gmail.com> From: Mary Barnes To: spromano@unina.it Content-Type: multipart/alternative; boundary=001485e7732af96b1c047edd4444 Cc: xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05 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, 05 Feb 2010 16:51:17 -0000 --001485e7732af96b1c047edd4444 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys, Sorry for the delay in getting into the details of this thread. I have a couple comments below [MB]. Thanks, Mary. On Mon, Jan 25, 2010 at 1:03 PM, wrote: > Hi Sean, > > > Hi All, >> I would like some clarification on the use of the >> element with the CCMP protocol. >> My understanding is that this element is not returned in confResponse >> where a conference is cloned from a blueprint. Is that correct? >> > > [spromano] Yes, it is. > > > >> What if I want to clone an existing conference? Would the >> element be returned in the confResponse? >> > > [spromano] Yes. > > > >> If a conference has a element, does that imply that it >> inherits attributes not specified in its conference object from the >> parent that is specified by the ? >> > > [spromano] From your comment I derive that you're envisaging a scenario i= n > which I can clone a conference by issuing a confRequest/create message > containing a conference document which explicitely states its will of bei= ng > created as a clone of an existing one. This is done by providing the XCON > URI of the parent object inside the element. Is this rig= ht? > Indeed, the only way to clone a conference object is (see section 5.3 in > draft-ietf-xcon-examples-02) by sending a confRequest/create message to t= he > server, with no conference document attached and with the XCON-URI of the > object-to-be-cloned in the confObjID parameter. Subsequent updates to suc= h > new document can be made through confRequest/update messages. > > Note that the element is created by the server and sent > back to the client. > > > And if a parent obect >> is modified, these changes would be applied to its children also by the >> server? >> I recall a while back that it may be possible to specify what attributes >> can be overridden by a child conference. How is that achieved? >> >> Finally, I assume CCMP would support the possibility to break this >> parent/child relationship, by sending an confRequest update with an >> empty element? >> >> I think the ccmp draft needs to add in some more detail and possibly >> examples for cloning conferences ... >> > > > [spromano] This part is quite tricky, indeed. Though, this is not related > to the CCMP. Cloning and associated policies are treated in RFC 5239, > section 7.1 (Cloning Tree). Our interpretation of such part of the framew= ork > is that the so-called "parent-enforceable" mechanism is something hidden > from the clients (i.e. it is a server-specific issue). If this were not t= he > case, then the data model should contain a boolean "parent-enforceable" > attribute for all elements that can be subject to such mechanism, which i= s > not the case at this moment. > > Do Mary, Oscar and the other authors of the mentioned documents (RFC 5239 > and draft-ietf-xcon-common-data-model) confirm our assumption? > [MB] We actually had this same thread of discussion almost a year ago and = I was asking this same question: http://www.ietf.org/mail-archive/web/xcon/current/msg02205.html I do still believe that the client needs this information. Certainly some clients won't be able to use it, but I think other more intelligent clients might. As I recall, the attribute was added based on this discussion, but I think we still need the independent (or not) attribute. [/MB] > > Thanks again for your invaluable feedback! > > > Simon > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon > --001485e7732af96b1c047edd4444 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,
=A0
Sorry for the delay in getting into the details of this thread. I have= a couple comments below [MB].
=A0
Thanks,
Mary.

On Mon, Jan 25, 2010 at 1:03 PM, <spromano@unina.it> wrote:
Hi Sean,=20


Hi All,
=A0 =A0 =A0 =A0I woul= d like some clarification on the use of the
<cloning-parent> eleme= nt with the CCMP protocol.
My understanding is that this element is not returned in confResponse
wh= ere a conference is cloned from a blueprint. Is that correct?

[spromano] Yes, it is.=20



What if I want to clone an e= xisting conference? Would the
<cloning-parent> element be returned= in the confResponse?

[spromano] Yes.=20



If a conference has a <cl= oning-parent> element, does that imply that it
inherits attributes no= t specified in its conference object from the
parent that is specified by the <cloning parent>?
[spromano] From your comment I derive that you're envisaging a s= cenario in which I can clone a conference by issuing a confRequest/create m= essage containing a conference document which explicitely states its will o= f being created as a clone of an existing one. This is done by providing th= e XCON URI of the parent object inside the <cloning-parent> element. = Is this right? Indeed, the only way to clone a conference object is (see se= ction 5.3 in draft-ietf-xcon-examples-02) by sending a confRequest/create m= essage to the server, with no conference document attached and with the XCO= N-URI of the object-to-be-cloned in the confObjID parameter. Subsequent upd= ates to such new document can be made through confRequest/update messages.<= br>
Note that the <cloning-parent> element is created by the server a= nd sent back to the client.=20


And if a parent obect
is modi= fied, these changes would be applied =A0to its children also by the
serv= er?
I recall a while back that it may be possible to specify what attributescan be overridden by a child conference. How is that achieved?

Fina= lly, I assume CCMP would support the possibility to break this
parent/ch= ild relationship, by sending an confRequest update with an
empty <cloning-parent> element?

I think the ccmp draft needs t= o add in some more detail and possibly
examples for cloning conferences = ...


[spromano] This part is quite tricky, ind= eed. Though, this is not related to the CCMP. Cloning and associated polici= es are treated in RFC 5239, section 7.1 (Cloning Tree). Our interpretation = of such part of the framework is that the so-called "parent-enforceabl= e" mechanism is something hidden from the clients (i.e. it is a server= -specific issue). If this were not the case, then the data model should con= tain a boolean "parent-enforceable" attribute for all elements th= at can be subject to such mechanism, which is not the case at this moment.<= br>
Do Mary, Oscar and the other authors of the mentioned documents (RFC 52= 39 and draft-ietf-xcon-common-data-model) confirm our assumption?
[MB] We actually=A0 had this same thread of discussion almost a year a= go and I was asking this same question:
http://www.ietf.org/mail-archive/web/xcon/current/msg02205.html
=A0
=A0I do still believe that the client needs this information. Certainl= y some clients won't be able to use it, but I think other more intellig= ent clients might.=A0 As I recall, the <cloning-parent> attribute was= added based on this discussion, but I think we still need the independent = (or not) attribute.
[/MB]

Thanks again for your invalu= able feedback!=20


Simon


--
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_\\|//_
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0( O-O )
=A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~= ~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Simon Piet= ro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0Universita' di Napoli Federico II
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 Computer Science Department
=A0 =A0 =A0 =A0Phon= e: +39 081 7683823 -- Fax: +39 081 7684219
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0e-mail: spromano@= unina.it

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

____= ___________________________________________

--001485e7732af96b1c047edd4444-- From duddy@avaya.com Tue Feb 9 09:59:52 2010 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 F0A0128C154 for ; Tue, 9 Feb 2010 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vq6hfYiVeVoI for ; Tue, 9 Feb 2010 09:59:51 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 3970D3A71CD for ; Tue, 9 Feb 2010 09:59:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,437,1262581200"; d="scan'208,217";a="204357767" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Feb 2010 13:00:57 -0500 X-IronPort-AV: E=Sophos;i="4.49,437,1262581200"; d="scan'208,217";a="429633428" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Feb 2010 13:00:41 -0500 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_01CAA9B1.CA04AF8E" Date: Tue, 9 Feb 2010 18:01:57 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D2305@306900ANEX2.global.avaya.com> In-Reply-To: <184b5e71002050851we7d5bbeme3cc5be326dcff52@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: Acqmg4zxcIszrwj/Qveoxduzo92DtQDK9EBw References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com> <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> <184b5e71002050851we7d5bbeme3cc5be326dcff52@mail.gmail.com> From: "Duddy, Sean (Sean)" To: "Mary Barnes" , Cc: xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05 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: Tue, 09 Feb 2010 17:59:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA9B1.CA04AF8E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Thanks for the clarfication on the items below. On the outstanding = issues:- =20 How could we encorporate a 'parent-enforceable' type attribute for = the elements already defined in rfc4575?=20 E.g it would be very useful to enforce the max conference = size(maximum-user-count), which is defined in rfc4575... =20 I mentioned below that I believe that CCMP protocol would be greatly = enhanced if a client could specify a conference doc with specific = settings for the conference clone operation. The typical scenario is, a client wants to use a known blueprint/working = conference but obviously wants a different name, that name could be = specified in the conf doc supplied in the clone operation. =20 Without this feature, it means two requests are required by the client. = Actually a more difficult situation is where clients specify passwords = for conferences, so if clone operation doesnt have the ability to supply new passwords, the CCMP server wont have the passwords for the = new conference and cant use the ones from the cloning parent....so what = does it do? =20 Sean=20 =20 =20 ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: 05 February 2010 16:52 To: spromano@unina.it Cc: Duddy, Sean (Sean); xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05 Hi guys, =20 Sorry for the delay in getting into the details of this thread. I have a = couple comments below [MB]. =20 Thanks, Mary. On Mon, Jan 25, 2010 at 1:03 PM, wrote: Hi Sean,=20 Hi All, I would like some clarification on the use of the element with the CCMP protocol. My understanding is that this element is not returned in confResponse where a conference is cloned from a blueprint. Is that correct? =09 [spromano] Yes, it is.=20 What if I want to clone an existing conference? Would the element be returned in the confResponse? =09 [spromano] Yes.=20 If a conference has a element, does that imply that = it inherits attributes not specified in its conference object from the parent that is specified by the ? =09 [spromano] From your comment I derive that you're envisaging a scenario = in which I can clone a conference by issuing a confRequest/create = message containing a conference document which explicitely states its = will of being created as a clone of an existing one. This is done by = providing the XCON URI of the parent object inside the = element. Is this right? Indeed, the only way to clone a conference = object is (see section 5.3 in draft-ietf-xcon-examples-02) by sending a = confRequest/create message to the server, with no conference document = attached and with the XCON-URI of the object-to-be-cloned in the = confObjID parameter. Subsequent updates to such new document can be made = through confRequest/update messages. =09 Note that the element is created by the server and = sent back to the client.=20 And if a parent obect is modified, these changes would be applied to its children also by = the server? I recall a while back that it may be possible to specify what = attributes can be overridden by a child conference. How is that achieved? =09 Finally, I assume CCMP would support the possibility to break this parent/child relationship, by sending an confRequest update with an empty element? =09 I think the ccmp draft needs to add in some more detail and possibly examples for cloning conferences ... =09 [spromano] This part is quite tricky, indeed. Though, this is not = related to the CCMP. Cloning and associated policies are treated in RFC = 5239, section 7.1 (Cloning Tree). Our interpretation of such part of the = framework is that the so-called "parent-enforceable" mechanism is = something hidden from the clients (i.e. it is a server-specific issue). = If this were not the case, then the data model should contain a boolean = "parent-enforceable" attribute for all elements that can be subject to = such mechanism, which is not the case at this moment. =09 Do Mary, Oscar and the other authors of the mentioned documents (RFC = 5239 and draft-ietf-xcon-common-data-model) confirm our assumption? =09 [MB] We actually had this same thread of discussion almost a year ago = and I was asking this same question: http://www.ietf.org/mail-archive/web/xcon/current/msg02205.html =20 I do still believe that the client needs this information. Certainly = some clients won't be able to use it, but I think other more intelligent = clients might. As I recall, the attribute was added = based on this discussion, but I think we still need the independent (or = not) attribute. [/MB] Thanks again for your invaluable feedback!=20 Simon =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 _______________________________________________ =09 XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon =09 ------_=_NextPart_001_01CAA9B1.CA04AF8E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
    Thanks for the clarfication = on the items=20 below. On the outstanding issues:-
 
    How could we encorporate a=20 'parent-enforceable' type attribute for the elements already defined in = rfc4575?=20
E.g it would be very useful to enforce the max = conference=20 size(maximum-user-count), which is defined  in=20 rfc4575...
 
I mentioned below that I believe that CCMP = protocol would=20 be greatly enhanced if a client could specify a conference doc with = specific=20 settings for the conference clone operation.
The typical scenario is, a client wants to use = a known=20 blueprint/working conference but obviously wants a different name, that = name=20 could be specified in the conf doc supplied in the clone=20 operation.
 
Without this feature, it means two requests are = required by=20 the client. Actually a more difficult situation is where clients specify = passwords for conferences, so if clone operation doesnt have the ability = to
supply new passwords, the CCMP server wont have = the=20 passwords for the new conference and cant use the ones from the cloning=20 parent....so what does it do?
 
Sean 
 
 
From: = Mary Barnes=20 [mailto:mary.ietf.barnes@gmail.com]
Sent: 05 February 2010=20 16:52
To: spromano@unina.it
Cc: Duddy, Sean (Sean);=20 xcon@ietf.org
Subject: Re: [XCON] Comments on=20 draft-ietf-xcon-ccmp-05

Hi guys,
 
Sorry for the delay in getting into the details of this thread. I = have a=20 couple comments below [MB].
 
Thanks,
Mary.

On Mon, Jan 25, 2010 at 1:03 PM, <spromano@unina.it> = wrote:
Hi=20 Sean,=20


Hi=20 All,
       I would like some clarification = on the=20 use of the
<cloning-parent> element with the CCMP = protocol.
My=20 understanding is that this element is not returned in = confResponse
where=20 a conference is cloned from a blueprint. Is that=20 correct?

[spromano] Yes, it is.=20



What=20 if I want to clone an existing conference? Would=20 the
<cloning-parent> element be returned in the=20 confResponse?

[spromano] Yes.=20



If=20 a conference has a <cloning-parent> element, does that imply = that=20 it
inherits attributes not specified in its conference object = from=20 the
parent that is specified by the <cloning=20 parent>?

[spromano] From your comment I = derive=20 that you're envisaging a scenario in which I can clone a conference by = issuing=20 a confRequest/create message containing a conference document which=20 explicitely states its will of being created as a clone of an existing = one.=20 This is done by providing the XCON URI of the parent object inside the = <cloning-parent> element. Is this right? Indeed, the only way to = clone a=20 conference object is (see section 5.3 in draft-ietf-xcon-examples-02) = by=20 sending a confRequest/create message to the server, with no conference = document attached and with the XCON-URI of the object-to-be-cloned in = the=20 confObjID parameter. Subsequent updates to such new document can be = made=20 through confRequest/update messages.

Note that the=20 <cloning-parent> element is created by the server and sent back = to the=20 client.=20


And=20 if a parent obect
is modified, these changes would be applied =  to=20 its children also by the
server?
I recall a while back that it = may be=20 possible to specify what attributes
can be overridden by a child=20 conference. How is that achieved?

Finally, I assume CCMP = would=20 support the possibility to break this
parent/child relationship, = by=20 sending an confRequest update with an
empty = <cloning-parent>=20 element?

I think the ccmp draft needs to add in some more = detail and=20 possibly
examples for cloning conferences=20 ...


[spromano] This part is quite = tricky,=20 indeed. Though, this is not related to the CCMP. Cloning and = associated=20 policies are treated in RFC 5239, section 7.1 (Cloning Tree). Our=20 interpretation of such part of the framework is that the so-called=20 "parent-enforceable" mechanism is something hidden from the clients = (i.e. it=20 is a server-specific issue). If this were not the case, then the data = model=20 should contain a boolean "parent-enforceable" attribute for all = elements that=20 can be subject to such mechanism, which is not the case at this=20 moment.

Do Mary, Oscar and the other authors of the mentioned = documents=20 (RFC 5239 and draft-ietf-xcon-common-data-model) confirm our=20 assumption?
[MB] We actually  had this same thread of discussion almost a = year ago=20 and I was asking this same question:
= http://www.ietf.org/mail-archive/web/xcon/current/msg02205.html
=
 
 I do still believe that the client needs this information. = Certainly=20 some clients won't be able to use it, but I think other more intelligent = clients=20 might.  As I recall, the <cloning-parent> attribute was added = based=20 on this discussion, but I think we still need the independent (or not)=20 attribute.
[/MB]

Thanks=20 again for your invaluable feedback!=20


Simon


--
      =  =20                  =20  _\\|//_
              =  =20            ( O-O )
 =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 list
XCON@ietf.org
https://www.ietf.org/mailman/listinfo/xcon
<= /DIV>

------_=_NextPart_001_01CAA9B1.CA04AF8E-- From root@core3.amsl.com Wed Feb 10 00:15:03 2010 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3179728C143; Wed, 10 Feb 2010 00:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100210081503.3179728C143@core3.amsl.com> Date: Wed, 10 Feb 2010 00:15:03 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-15.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: Wed, 10 Feb 2010 08:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-15.txt Pages : 94 Date : 2010-02-09 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-10001127.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Feb 11 05:00:01 2010 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F00D3A7063; Thu, 11 Feb 2010 05:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100211130001.8F00D3A7063@core3.amsl.com> Date: Thu, 11 Feb 2010 05:00:01 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-16.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: Thu, 11 Feb 2010 13:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-16.txt Pages : 94 Date : 2010-02-11 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-11045118.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Feb 17 08:30:01 2010 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C15C63A7B55; Wed, 17 Feb 2010 08:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100217163001.C15C63A7B55@core3.amsl.com> Date: Wed, 17 Feb 2010 08:30:01 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.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: Wed, 17 Feb 2010 16:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-06.txt Pages : 101 Date : 2010-02-17 The Centralized Conferencing Manipulation Protocol (CCMP) allows a XCON conferencing system client to create, retrieve, change and delete objects describing a centralized conference, being a mean to control basic and advanced conference features such as conference state and capabilities, participants and relative roles and details. The CCMP is a state-less, XML-based, client server protocol carrying in its request and response messages conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-ccmp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-17082230.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Feb 17 08:45:02 2010 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1400A28C0E1; Wed, 17 Feb 2010 08:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100217164502.1400A28C0E1@core3.amsl.com> Date: Wed, 17 Feb 2010 08:45:02 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-examples-03.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: Wed, 17 Feb 2010 16:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-examples-03.txt Pages : 85 Date : 2010-02-17 This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-examples-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-17084337.I-D@ietf.org> --NextPart-- From spromano@unina.it Wed Feb 17 08:47:13 2010 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 F3BE63A7D43 for ; Wed, 17 Feb 2010 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.575 X-Spam-Level: * X-Spam-Status: No, score=1.575 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_50=0.001, 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 qrbxPl+asI9r for ; Wed, 17 Feb 2010 08:47:12 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 4E35A3A7B55 for ; Wed, 17 Feb 2010 08:47:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o1HGmlMC004338 for ; Wed, 17 Feb 2010 17:48:48 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Wed, 17 Feb 2010 17:48:47 +0100 Message-ID: <20100217174847.1oaonk5vmscoc00w@webmail.unina.it> Date: Wed, 17 Feb 2010 17:48:47 +0100 From: spromano@unina.it To: xcon@ietf.org 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/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it X-Virus-Status: Clean Subject: [XCON] New versions of CCMP and XCON call flows drafts 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: Wed, 17 Feb 2010 16:47:13 -0000 Dear all, I just uploaded the new versions of the drafts mentioned in the =20 subject. As you will notice, the CCMP document now reflects the latest =20 discussions we had on the mailing list. As to the call flows, they are =20 up to date with respect to the new content of the CCMP draft (our =20 implementation has been updated as well). Cheers, Simon --=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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From duddy@avaya.com Wed Feb 17 09:59:25 2010 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 6009A3A79E7 for ; Wed, 17 Feb 2010 09:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 8XCgwrhKC0hC for ; Wed, 17 Feb 2010 09:59:24 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 43F573A76D7 for ; Wed, 17 Feb 2010 09:59:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,492,1262581200"; d="scan'208";a="205558909" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Feb 2010 13:01:02 -0500 X-IronPort-AV: E=Sophos;i="4.49,492,1262581200"; d="scan'208";a="432570333" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Feb 2010 13:00:47 -0500 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: Wed, 17 Feb 2010 18:00:26 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F7101101281@306900ANEX2.global.avaya.com> In-Reply-To: <20100217164502.1400A28C0E1@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-examples-03.txt Thread-Index: Acqv8SU1UKwUYUhCQtybnvas0fRZcAABO4Nw References: <20100217164502.1400A28C0E1@core3.amsl.com> From: "Duddy, Sean (Sean)" To: Subject: Re: [XCON] I-D Action:draft-ietf-xcon-examples-03.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: Wed, 17 Feb 2010 17:59:25 -0000 Hi All, I am wondering do we need some simpler sidebar example(s)? Or what is the suggested CCMP operations to move a particpant from the main conference to a sub conference. I am thinking the following CCMP operations can do it:- 1. sidebarByValRequest CREATE operation is sent to create sidebar 2. userRequest CREATE operation is sent to add user to sidebar conference. I assume moving a user from the parent conference to a sidebar should be done using steps 1 & 2 followed by a userRequest DELETE on parent conference=20 I am just wondering do we need the sidebar(s)By*Request at all for the update and delete operations?=20 I think once the sidebar is created, it can be manipulated like the parent conferences using the confRequest operations.... Sean =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 17 February 2010 16:45 To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-examples-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-examples-03.txt Pages : 85 Date : 2010-02-17 This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From duddy@avaya.com Wed Feb 17 10:26:45 2010 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 5E16B28C186 for ; Wed, 17 Feb 2010 10:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 kDnehRKBvQa3 for ; Wed, 17 Feb 2010 10:26:44 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1011E28C0DF for ; Wed, 17 Feb 2010 10:26:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,492,1262581200"; d="scan'208";a="176907837" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Feb 2010 13:28:20 -0500 X-IronPort-AV: E=Sophos;i="4.49,492,1262581200"; d="scan'208";a="446768014" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Feb 2010 13:28:20 -0500 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: Wed, 17 Feb 2010 18:28:01 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F7101101293@306900ANEX2.global.avaya.com> In-Reply-To: <20100217163001.C15C63A7B55@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt Thread-Index: Acqv7yErDxgRbWOwRI2pXTur60X9MwADYXWw References: <20100217163001.C15C63A7B55@core3.amsl.com> From: "Duddy, Sean (Sean)" To: Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.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: Wed, 17 Feb 2010 18:26:45 -0000 Hi, I think we need a response code when the CCMP server cannot execute a command because of resource issues. E.g. CCMP server cannot create a sub conference Because the system has reached its limits on the no. of sub conferences, Of if the addUser request fails because the max number of users has been reached for the conference or the max number of users has been reached for the conferencing system... Maybe a=20 resourcesNotAvailable response code? Sean -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 17 February 2010 16:30 To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-06.txt Pages : 101 Date : 2010-02-17 The Centralized Conferencing Manipulation Protocol (CCMP) allows a XCON conferencing system client to create, retrieve, change and delete objects describing a centralized conference, being a mean to control basic and advanced conference features such as conference state and capabilities, participants and relative roles and details. The CCMP is a state-less, XML-based, client server protocol carrying in its request and response messages conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From duddy@avaya.com Thu Feb 18 07:14:07 2010 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 B850228C1D7 for ; Thu, 18 Feb 2010 07:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 xDHLmqB0SZaL for ; Thu, 18 Feb 2010 07:14:06 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2E20828C13D for ; Thu, 18 Feb 2010 07:14:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,497,1262581200"; d="scan'208";a="177040016" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Feb 2010 10:15:46 -0500 X-IronPort-AV: E=Sophos;i="4.49,497,1262581200"; d="scan'208";a="432938779" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.153]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Feb 2010 10:15:11 -0500 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: Thu, 18 Feb 2010 15:14:58 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F710110137E@306900ANEX2.global.avaya.com> In-Reply-To: <20100211130001.8F00D3A7063@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-common-data-model-16.txt Thread-Index: AcqrGlAb7H7kZLp/SJCqY+bGgjP+/wFkkMRQ References: <20100211130001.8F00D3A7063@core3.amsl.com> From: "Duddy, Sean (Sean)" To: Subject: Re: [XCON] I-D Action:draft-ietf-xcon-common-data-model-16.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: Thu, 18 Feb 2010 15:14:07 -0000 Hi All, needs to be an XML element referring to the type below... The draft xsd just defines the type but no element... Sean From oscar.novo@ericsson.com Wed Feb 24 03:22:29 2010 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 849B03A77B5 for ; Wed, 24 Feb 2010 03:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 ZX2ZOnix0aet for ; Wed, 24 Feb 2010 03:22:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6DBA63A6922 for ; Wed, 24 Feb 2010 03:22:28 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-11-4b850c71812f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B2.48.31641.17C058B4; Wed, 24 Feb 2010 12:24:33 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.2.28]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Feb 2010 12:24:27 +0100 From: Oscar Novo To: "Duddy, Sean (Sean)" , "xcon@ietf.org" Date: Wed, 24 Feb 2010 12:24:26 +0100 Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-common-data-model-16.txt Thread-Index: AcqrGlAb7H7kZLp/SJCqY+bGgjP+/wFkkMRQASW6ReA= Message-ID: <209F0863F938D249AFDC024EC4C9E3E20EAF862607@ESESSCMS0353.eemea.ericsson.se> References: <20100211130001.8F00D3A7063@core3.amsl.com> <4408C6EC74CC3D42824FD68FDA8E8F710110137E@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F710110137E@306900ANEX2.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] I-D Action:draft-ietf-xcon-common-data-model-16.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: Wed, 24 Feb 2010 11:22:29 -0000 Thanks Sean. I've submitted another version with the fix. Cheers, Oscar=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Dud= dy, Sean (Sean) Sent: 18. helmikuuta 2010 17:15 To: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-common-data-model-16.txt Hi All, needs to be an XML element referring to the type bel= ow... The draft xsd just defines the type but no element... Sean _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From root@core3.amsl.com Wed Feb 24 03:30:01 2010 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B94573A83E6; Wed, 24 Feb 2010 03:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100224113001.B94573A83E6@core3.amsl.com> Date: Wed, 24 Feb 2010 03:30:01 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-17.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: Wed, 24 Feb 2010 11:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-17.txt Pages : 94 Date : 2010-02-24 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-24031839.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Feb 24 08:00:01 2010 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B3EF83A8535; Wed, 24 Feb 2010 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100224160001.B3EF83A8535@core3.amsl.com> Date: Wed, 24 Feb 2010 08:00:01 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-18.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: Wed, 24 Feb 2010 16:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-18.txt Pages : 94 Date : 2010-02-24 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-24075251.I-D@ietf.org> --NextPart--