From root@core3.amsl.com Wed Apr 14 06:15: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 337B13A693F; Wed, 14 Apr 2010 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100414131502.337B13A693F@core3.amsl.com> Date: Wed, 14 Apr 2010 06:15:02 -0700 (PDT) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-examples-04.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, 14 Apr 2010 13:15: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-04.txt Pages : 83 Date : 2010-04-14 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14061355.I-D@ietf.org> --NextPart-- From spromano@unina.it Wed Apr 14 06:15: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 ECB983A6A11 for ; Wed, 14 Apr 2010 06:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[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 m2ZR6DVACGnz for ; Wed, 14 Apr 2010 06:15:07 -0700 (PDT) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 3B5F93A67FD for ; Wed, 14 Apr 2010 06:15:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o3EDEqN5004032; Wed, 14 Apr 2010 15:14:52 +0200 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Wed, 14 Apr 2010 15:14:52 +0200 Message-ID: <20100414151452.8f69evq5ogw8gsks@webmail.unina.it> Date: Wed, 14 Apr 2010 15:14:52 +0200 From: spromano@unina.it To: Gonzalo Camarillo References: <4B8FB489.8000206@ericsson.com> In-Reply-To: <4B8FB489.8000206@ericsson.com> 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 Cc: XCON Subject: Re: [XCON] Comments on 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, 14 Apr 2010 13:15:08 -0000 Dear Gonzalo, thank you for the helpful review! I have just uploaded a new version =20 of the call flows document, which takes into account all of the =20 comments you made, as well as some minor remarks made by Sean Duddy. =20 Please have a look at the current version of the draft and let us know =20 what is your feeling about it. Cheers, Simon Quoting Gonzalo Camarillo : > Hi, > > a few comments on the following document: > > http://www.ietf.org/id/draft-ietf-xcon-examples-03.txt > > This document provides an easy-to-read introduction to CCMP and a set of > useful call flows for those intending to get an overview of the > protocol. I have a few minor comments: > > Section 2 references RFC 2119. However, the intended status of this > document is Informational. Besides, the document does not seem to use > RFC 2119 normative language. That paragraph probably needs to removed. > > Section 3: > > "This document uses the same terminology as found in the referenced > documents" > > Can we be a bit more precise and actually reference the documents we > are talking about? > > Last paragraph of Section 4. For completness, it should also describe > the contents of Section 10 (i.e., the lack of IANA considerations). > > Section 5: s/indipendently/independently/ > > Section 5.2 > > "[I-D.ietf-xcon-ccmp] presents several ways by which CCMP requests and > responses can be transported" > > I may be mistaken but the CCMP spec does not seem to present different > transports for the protocol. I understood CCMP supports different > transports but the spec only describes the HTTP transport. We may want > to rephrase that sentence so that it talks about CCMP potentially > "supporting" different transport mechanisms instead. > > Also in Section 5.2: > > "...the Server would reply by means..." > > The term being used in the text seems to be ConfS, not Server. > > Section 5.3 describes the fact that the XCON notification mechanism is > based on SIP as a drawback because one needs a SIP stack to use it. It > would not present it as a drawback; simply as a fact. > > Also in Section 5.3: > > OLD: > other protocols as XMPP > > NEW > other protocols such as XMPP > > Section 7.2. The two first paragraphs talk about the relationship of > muting at the media level and floor control. In the past, there has > been some confusion around this. So, it may be worthwhile clarifying > that floor control and policy control at the media level are two > different things. You can have floor control that is not enforced in > any way, or floor control that is enforced at the media level (i.e., > the conference bridge will only accept your media if you have the > floor). Adding a couple of sentences explaining this would be helpful, > I think. > > Cheers, > > Gonzalo > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon > --=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 spromano@unina.it Mon Apr 26 02:58:57 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 872EF3A6A5A for ; Mon, 26 Apr 2010 02:58:57 -0700 (PDT) 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.698, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] 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 ptSTO-4wCRlJ for ; Mon, 26 Apr 2010 02:58:56 -0700 (PDT) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 757AB3A6AE4 for ; Mon, 26 Apr 2010 02:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o3Q9wYDo010663; Mon, 26 Apr 2010 11:58:35 +0200 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 26 Apr 2010 11:58:34 +0200 Message-ID: <20100426115834.lhvudl29s4kk8w40@webmail.unina.it> Date: Mon, 26 Apr 2010 11:58:34 +0200 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4408C6EC74CC3D42824FD68FDA8E8F710115C2D0@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F710115C2D0@306900ANEX2.global.avaya.com> 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 Cc: xcon@ietf.org 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: Mon, 26 Apr 2010 09:58:57 -0000 Hi Sean, please find in-line ([SIMON]) my answers to your comments and suggestions. > Hi All, > I am aware that this draft is nearing completion so I have listed all > my outstanding issues in this email. > > 1. If one wanted to move a user from one conference to another, how > could this be achieved via CCMP? It could be done with > a userRequest of Type CREATE on the new conference supplying the userID > of the existing user, with the password of the user's > existing conference. The password of the new target conference would > also be required which could be stuffed into the request's any > field... It would good to get other people's opinion this.... [SIMON] Let us first suppose we have a "registered" conferencing client, =20 characterized by: * xcon-userid: xcon:pippozzo@example.com * username: pippozzo * password: 131313 The system presumably keeps track of at least a signaling URI for such =20 user, since he already participates in a conference. This means that =20 join requests can avoid to bring a "userInfo" parameter (unless we =20 want to update the list of URIs associated with the user's =20 xcon-userid). We can have the following cases: **** case 1: entering a non password protected conference inside the userRequest/create we only need the following parameters: * confUserID =3D xcon-userid:pippozzo@example.com * confObjID of the conference we wish to join * operation =3D create **** case 2: entering a password protected conference( as in par. =20 7.5 of draft-ietf-xcon-examples-03 online) inside the userRequest/create we need the following parameters: * confUserID =3D xcon-userid:pippozzo@example.com * confObjID of the conference we wish to join * operation =3D create * conference-password =3D password associated with the conference =20 with id equal to confObjID *** case 3: user authentication required by the system before =20 entering a password protected conference inside the userRequest/create: * subject: username =3D pippozzo, password =3D 131313 * confUserID =3D xcon-userid:pippozzo@example.com * confObjID of the conference we wish to join * operation =3D create * conference-password =3D password of the conference we wish to join > > 2. Need clarification on the CCMP operations to move a user from a > parent conference to one of its sidebars and back again. > Simple example side related examples should be provided. [SIMON] I don't see any particular issue here. We have the following =20 scenarios: **** a) a user wants to exit the main conference and join a =20 sidebar; then, he wants to go back to the main conference (while =20 leaving the sidebar). We need 4 messages: * 1) userRequest/delete from the main conference * 2) userRequest/create on the sidebar * 3) userRequest/delete from the sidebar * 4) userRequest/create on the main conference **** b) a user wants to enter a sidebar while keeping on =20 participating in the main conference (i.e. he will also appear in the =20 roster of the main conference). Then, he wants to leave the previously =20 joined sidebar. We need 2 messages: * 1) userRequest/create on the sidebar * 2) userRequest/delete from the sidebar (when he wants to leave it). > > 3. CCMP response codes:- > 3.1 How does a server indicate to a client that it does not support the > setting of a XML element(s). i.e the request is a valid XML > request but part of it cannot be set... > 3.2 We need an ObjectAlreadyExists response code to indicate to a client > if it attempts to create an object with an entity that already exists. > e.g. an attempt to create a user that already exists in the system. > 3.3 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, > or 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 resourcesNotAvailable response code? [SIMON] As to response codes, we completely restructured the way they =20 are defined. We moved to IETF-style 3-digit codes, which have been =20 defined like this in the schema: =09 =09 =09=09 =09=09=09 =09=09 =09 The current list of codes is as follows: 200 Success: Successful completion of the requested operation. 400 Bad Request: Syntactically malformed request. 401 Unauthorized: User not allowed to perform the required operation. 403 Forbidden: Operation not allowed (e.g., cancellation of a blueprint). 404 Object Not Found: Target conference object missing at the server (it refers to the "confObjID" parameter in the generic request message) 409 Conflict: A generic error associated with all those situations in which a requested client operation cannot be successfully completed by the server. An example of such situation is when the modification of an object cannot be applied due to conflicts arising at the server's side, e.g. because the client version of the object is an obsolete one and the requested modifications collide with the up-to-date state of the object stored at the server. Such code would also be used if a client attempts to create an object (conference or user) with an entity that already exists. 420 User Not Found: Target user missing at the server (it is related to the XCON-USERID in the "entity" attribute of the "userInfo" parameter when it is included in userRequests) 421 Invalid confUserID: User missing at the server (this code is returned in the case of requests in which the "confUserID" of the sender is invalid). 422 Invalid Conference Password: Target conference object's password contained in the request is wrong. 423 Conference Password Required: "conference-password" missing in a request to access a password-protected conference object. 424 Authentication Required: User's authentication information missing in a request to perform the requested operation. "subject" parameter needed in the request. 425 Forbidden Delete Parent: Cancel operation failed since the target object is a parent of child objects which depend on it, or because it effects, based on the "parent-enforceable" mechanism, the corresponding element in a child object. 426 Forbidden Change Protected: Update refused by the server because the target element cannot be modified due to its implicit dependence on the value of a parent object ("parent-enforceable" mechanism). 500 Server Internal Error: The server cannot complete the required service due to a system internal error. 501 Not Implemented: Operation envisaged in the protocol, but not implemented in the contacted server. 510 Request Timeout: The time required to serve the request has exceeded the envisaged service threshold. 511 Resources Not Available: This code is used when the CCMP server cannot execute a command because of resource issues, e.g. it cannot create a sub conference because the system has reached its limits on the number of sub conferences, or if a request for adding a new user 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. As you will notice, code 511 has been introduced based on your =20 suggestion in 3.3 above. 3.2 belongs in the 409 ("Conflict") category. =20 As to 3.1, I think it might fall in the 501 ("Not Implemented)" =20 category, if the case is that of a "valid" request which cannot be =20 satisfied by the server because it either does not modify certain =20 'standard' parameters of the conf document or does not recognize =20 'special' elements which are there beacuse of the "any" in the schema. In case the problem is instead due to the lack of resources at the =20 server side, then the newly introduced 511 (Resources Not Available) =20 can do the job. What do you think about this? > > 4. General CCMP comment:- I am wondering if the CCMP request XML could > be reduced/simplified. E.g. > > > > > > > > > > > > > > > > > > type=3D"info:conference-type" minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > could this request be represented also as follows: > > > > > > type=3D"info:conference-type" minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > The same pattern could be applied to the other requests and the > responses also... [SIMON] I personally find the current structure more readable. Though, =20 I'm open to change the current schema if people see it fit. > > 5. Also it might be an idea to facilitate the possibility of specifying > new requests. The CCMP xsd could expose another Request/Response pair to > faciliate this e.g. > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > Or what should implementors do if they want to expose requests other > than those in the CCMP draft? [SIMON] Totally agreed. We added your proposal to the CCMP schema. > > 6. I mentioned a while back that 100% support of all XPATH filters could > be problematic for implementors, specifically > in relation to peformance. I think it might be worth indicating that > implementors may support only a set of documented XPATH filters.... [SIMON] I think we already discussed this point. I'm cutting and =20 pasting Richard Barnes' answer from an e-mail of January 25th 2010: ******************************************************************** "It's not clear to me how using a subset of XPath queries creates any benefit here. There are several XPath libraries out there that cover the complete spec, so it's not hard for CCMP implementations can get full XPath by using one of them. And the alternatives seem undesirable, e.g., matching against fixed XPath literals or hacking up some incomplete implementation of XPath. I would recommend leaving the document as-is. Richard Barnes" ********************************************************************** > > 7. I mentioned a while back that it would be very useful to allow > conference cloning requests to also contain a conference doc that > contains > specific modications required to the cloned conference like new > conference name. This would avoid having to send a seperate update and > would > guarantee that clients get what they want in one server transaction. [SIMON] In the draft we currently write: **************************************************************************** The creation case deserves care. To create a new conference through =20 a "confRequest" message, two approaches can be considered: 1. Creation through explicit cloning: the "confObjID" parameter =20 MUST contain the XCON-URI of the blueprint or of the conference to be =20 cloned, while the "confInfo" parameter MUST NOT be included in the =20 confRequest; 2. Creation through implicit cloning (also known as "direct =20 creation"): the "confObjID" parameter MUST NOT be included in the =20 request and the CCMP client can describe the desired conference to be =20 created using the "confInfo" parameter. If no "confInfo" parameter is =20 provided in the request, the new conference will be created as a clone =20 of the system default blueprint. ****************************************************************************= ** I think you are suggesting to remove the sentence with "MUST NOT" from =20 the first paragraph (associated with case 1. in the draft). It was our =20 intention to somehow "drive" the clone-based creation of a conference =20 through lean and mean operations: you first obtain a clone of the =20 parent conference and then you modify it through subsequent update =20 operations. Here again, we are open to change this in the document if =20 others deem it worth. > > 8. The examples in the ccmp draft and the examples draft should contain > references to the new element. [SIMON] This has already been done. What we have to mdify there (if =20 the WG agrees on their new definitions) are the response-codes in the =20 dumps. > > Regards > Sean [SIMON] Thank you once again for your invaluable feedback! 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 root@core3.amsl.com Mon Apr 26 03:15: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 7A1BE28C0EA; Mon, 26 Apr 2010 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100426101501.7A1BE28C0EA@core3.amsl.com> Date: Mon, 26 Apr 2010 03:15:01 -0700 (PDT) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:15: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-07.txt Pages : 93 Date : 2010-04-26 The Centralized Conferencing Manipulation Protocol (CCMP) allows an XCON conferencing system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a state-less, XML-based, client server protocol that carries, 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-07.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-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-26030308.I-D@ietf.org> --NextPart-- From duddy@avaya.com Mon Apr 26 04:15:20 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 8B3523A6B86 for ; Mon, 26 Apr 2010 04:15:20 -0700 (PDT) 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 0nLm2HQF2Oho for ; Mon, 26 Apr 2010 04:15:18 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 6E2043A6B73 for ; Mon, 26 Apr 2010 04:15:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,273,1270440000"; d="scan'208";a="13168161" 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; 26 Apr 2010 07:15:04 -0400 X-IronPort-AV: E=Sophos;i="4.52,273,1270440000"; d="scan'208";a="454929705" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.153]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Apr 2010 07:14:33 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2010 12:15:24 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71011BB4B8@306900ANEX2.global.avaya.com> In-Reply-To: <20100426115834.lhvudl29s4kk8w40@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt Thread-Index: AcrlJw3n/+vWytkPTOeNTXH85vBQNAABo7BA References: <4408C6EC74CC3D42824FD68FDA8E8F710115C2D0@306900ANEX2.global.avaya.com> <20100426115834.lhvudl29s4kk8w40@webmail.unina.it> From: "Duddy, Sean (Sean)" To: Cc: xcon@ietf.org 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: Mon, 26 Apr 2010 11:15:20 -0000 Hi Simon, Thanks very much for sticking with me on this ...=20 See below:- -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 26 April 2010 10:59 To: Duddy, Sean (Sean) Cc: xcon@ietf.org; spromano@unina.it Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt Hi Sean, please find in-line ([SIMON]) my answers to your comments and = suggestions. > Hi All, > I am aware that this draft is nearing completion so I have listed all = > my outstanding issues in this email. > > 1. If one wanted to move a user from one conference to another, how=20 > could this be achieved via CCMP? It could be done with a userRequest=20 > of Type CREATE on the new conference supplying the userID of the=20 > existing user, with the password of the user's existing conference.=20 > The password of the new target conference would also be required which = > could be stuffed into the request's any field... It would good to get=20 > other people's opinion this.... [SIMON] Let us first suppose we have a "registered" conferencing client, = characterized by: * xcon-userid: xcon:pippozzo@example.com * username: pippozzo * password: 131313 The system presumably keeps track of at least a signaling URI for such = user, since he already participates in a conference. This means that = join requests can avoid to bring a "userInfo" parameter (unless we want = to update the list of URIs associated with the user's xcon-userid). We = can have the following cases: **** case 1: entering a non password protected conference inside the userRequest/create we only need the following parameters: * confUserID =3D xcon-userid:pippozzo@example.com * confObjID of the conference we wish to join * operation =3D create **** case 2: entering a password protected conference( as in par. =20 7.5 of draft-ietf-xcon-examples-03 online) inside the userRequest/create we need the following parameters: * confUserID =3D xcon-userid:pippozzo@example.com * confObjID of the conference we wish to join * operation =3D create * conference-password =3D password associated with the conference = with id equal to confObjID *** case 3: user authentication required by the system before = entering a password protected conference inside the userRequest/create: * subject: username =3D pippozzo, password =3D 131313 * confUserID =3D xcon-userid:pippozzo@example.com * confObjID of the conference we wish to join * operation =3D create * conference-password =3D password of the conference we wish to join [SEAN] The thing is if I am moderator of my conference and I want = xcon-userid:pippozzo@example.com to join it, I could send the above cmd and xcon-userid:pippozzo@example.com would be placed in it = without having knowledge of the moderator passcode of=20 xcon-userid:pippozzo@example.com's existing conference? I think the cmd = needs to have both passcodes... > > 2. Need clarification on the CCMP operations to move a user from a=20 > parent conference to one of its sidebars and back again. > Simple example side related examples should be provided. [SIMON] I don't see any particular issue here. We have the following scenarios: **** a) a user wants to exit the main conference and join a sidebar; = then, he wants to go back to the main conference (while leaving the = sidebar). We need 4 messages: * 1) userRequest/delete from the main conference [SEAN] How does the server know that the client wants the user to enter = a sidebar as opposed to just deleting the user from the main conference? * 2) userRequest/create on the sidebar * 3) userRequest/delete from the sidebar [SEAN] How does the server know that the client wants the user to join = back in to the main conference as opposed to just deleting the user from = the sidebar conference? * 4) userRequest/create on the main conference **** b) a user wants to enter a sidebar while keeping on = participating in the main conference (i.e. he will also appear in the = roster of the main conference). Then, he wants to leave the previously = joined sidebar. We need 2 messages: * 1) userRequest/create on the sidebar * 2) userRequest/delete from the sidebar (when he wants to leave = it). > > 3. CCMP response codes:- > 3.1 How does a server indicate to a client that it does not support=20 > the setting of a XML element(s). i.e the request is a valid XML=20 > request but part of it cannot be set... > 3.2 We need an ObjectAlreadyExists response code to indicate to a=20 > client if it attempts to create an object with an entity that already = exists. > e.g. an attempt to create a user that already exists in the system. > 3.3 We need a response code when the CCMP server cannot execute a=20 > command because of resource issues. E.g. CCMP server cannot create a=20 > sub conference because the system has reached its limits on the no. of = > sub conferences, or if the addUser request fails because the max=20 > number of users has been reached for the conference or the max number=20 > of users has been reached for the conferencing system... > Maybe a resourcesNotAvailable response code? [SIMON] As to response codes, we completely restructured the way they = are defined. We moved to IETF-style 3-digit codes, which have been = defined like this in the schema: The current list of codes is as follows: 200 Success: Successful completion of the requested operation. 400 Bad Request: Syntactically malformed request. 401 Unauthorized: User not allowed to perform the required operation. 403 Forbidden: Operation not allowed (e.g., cancellation of a blueprint). 404 Object Not Found: Target conference object missing at the = server (it refers to the "confObjID" parameter in the generic request message) 409 Conflict: A generic error associated with all those situations in which a requested client operation cannot be successfully completed by the server. An example of such situation is when = the modification of an object cannot be applied due to conflicts arising at the server's side, e.g. because the client version of the object is an obsolete one and the requested modifications collide with the up-to-date state of the object stored at the server. Such code would also be used if a client attempts to create an object (conference or user) with an entity that already exists. 420 User Not Found: Target user missing at the server (it is = related to the XCON-USERID in the "entity" attribute of the "userInfo" parameter when it is included in userRequests) 421 Invalid confUserID: User missing at the server (this code is returned in the case of requests in which the "confUserID" of the sender is invalid). 422 Invalid Conference Password: Target conference object's = password contained in the request is wrong. 423 Conference Password Required: "conference-password" missing in = a request to access a password-protected conference object. 424 Authentication Required: User's authentication information missing in a request to perform the requested operation. = "subject" parameter needed in the request. 425 Forbidden Delete Parent: Cancel operation failed since the target object is a parent of child objects which depend on it, or because it effects, based on the "parent-enforceable" mechanism, the corresponding element in a child object. 426 Forbidden Change Protected: Update refused by the server = because the target element cannot be modified due to its implicit dependence on the value of a parent object ("parent-enforceable" mechanism). 500 Server Internal Error: The server cannot complete the required service due to a system internal error. 501 Not Implemented: Operation envisaged in the protocol, but not implemented in the contacted server. 510 Request Timeout: The time required to serve the request has exceeded the envisaged service threshold. 511 Resources Not Available: This code is used when the CCMP server cannot execute a command because of resource issues, e.g. it cannot create a sub conference because the system has reached its limits on the number of sub conferences, or if a request for adding a new user 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. As you will notice, code 511 has been introduced based on your = suggestion in 3.3 above. 3.2 belongs in the 409 ("Conflict") category. =20 As to 3.1, I think it might fall in the 501 ("Not Implemented)" =20 category, if the case is that of a "valid" request which cannot be = satisfied by the server because it either does not modify certain = 'standard' parameters of the conf document or does not recognize = 'special' elements which are there beacuse of the "any" in the schema. In case the problem is instead due to the lack of resources at the = server side, then the newly introduced 511 (Resources Not Available) can = do the job. What do you think about this? [SEAN] sounds good to me. > > 4. General CCMP comment:- I am wondering if the CCMP request XML could = > be reduced/simplified. E.g. > > > > > > > > > > > > > > > > > > type=3D"info:conference-type" minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > could this request be represented also as follows: > > > > > > type=3D"info:conference-type" minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > The same pattern could be applied to the other requests and the=20 > responses also... [SIMON] I personally find the current structure more readable. Though, = I'm open to change the current schema if people see it fit. > > 5. Also it might be an idea to facilitate the possibility of = specifying > new requests. The CCMP xsd could expose another Request/Response pair = to > faciliate this e.g. > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > Or what should implementors do if they want to expose requests other > than those in the CCMP draft? [SIMON] Totally agreed. We added your proposal to the CCMP schema. [SEAN] thanks > > 6. I mentioned a while back that 100% support of all XPATH filters = could > be problematic for implementors, specifically > in relation to peformance. I think it might be worth indicating that > implementors may support only a set of documented XPATH filters.... [SIMON] I think we already discussed this point. I'm cutting and =20 pasting Richard Barnes' answer from an e-mail of January 25th 2010: ******************************************************************** "It's not clear to me how using a subset of XPath queries creates any benefit here. There are several XPath libraries out there that cover the complete spec, so it's not hard for CCMP implementations can get full XPath by using one of them. And the alternatives seem undesirable, e.g., matching against fixed XPath literals or hacking up some incomplete implementation of XPath. I would recommend leaving the document as-is. Richard Barnes" ********************************************************************** [SEAN] OK > > 7. I mentioned a while back that it would be very useful to allow > conference cloning requests to also contain a conference doc that > contains > specific modications required to the cloned conference like new > conference name. This would avoid having to send a seperate update and > would > guarantee that clients get what they want in one server transaction. [SIMON] In the draft we currently write: *************************************************************************= *** The creation case deserves care. To create a new conference through =20 a "confRequest" message, two approaches can be considered: 1. Creation through explicit cloning: the "confObjID" parameter =20 MUST contain the XCON-URI of the blueprint or of the conference to be =20 cloned, while the "confInfo" parameter MUST NOT be included in the =20 confRequest; 2. Creation through implicit cloning (also known as "direct =20 creation"): the "confObjID" parameter MUST NOT be included in the =20 request and the CCMP client can describe the desired conference to be =20 created using the "confInfo" parameter. If no "confInfo" parameter is =20 provided in the request, the new conference will be created as a clone =20 of the system default blueprint. *************************************************************************= ***** I think you are suggesting to remove the sentence with "MUST NOT" from =20 the first paragraph (associated with case 1. in the draft). It was our =20 intention to somehow "drive" the clone-based creation of a conference =20 through lean and mean operations: you first obtain a clone of the =20 parent conference and then you modify it through subsequent update =20 operations. Here again, we are open to change this in the document if =20 others deem it worth. [SEAN] Lean and mean operations are a desirable goal but also we should = try to limit the number of requests A client has to send. The clone operation is a very quick way to get = conferences created but I Do believe adding the ability to overide params in the clone operation = via the confInfo param enhances the=20 Clone operation > > 8. The examples in the ccmp draft and the examples draft should = contain > references to the new element. [SIMON] This has already been done. What we have to mdify there (if =20 the WG agrees on their new definitions) are the response-codes in the =20 dumps. > > Regards > Sean [SIMON] Thank you once again for your invaluable feedback! 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 spromano@unina.it Mon Apr 26 11:11:03 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 035EC3A69D6 for ; Mon, 26 Apr 2010 11:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.928 X-Spam-Level: ** X-Spam-Status: No, score=2.928 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] 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 6zKgs2F8cne0 for ; Mon, 26 Apr 2010 11:11:02 -0700 (PDT) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id BA8203A6840 for ; Mon, 26 Apr 2010 11:11:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o3QIAjOA003201; Mon, 26 Apr 2010 20:10:46 +0200 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 26 Apr 2010 20:10:45 +0200 Message-ID: <20100426201045.8x0hgw8rkkw488cs@webmail.unina.it> Date: Mon, 26 Apr 2010 20:10:45 +0200 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4408C6EC74CC3D42824FD68FDA8E8F710115C2D0@306900ANEX2.global.avaya.com> <20100426115834.lhvudl29s4kk8w40@webmail.unina.it> <4408C6EC74CC3D42824FD68FDA8E8F71011BB4B8@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71011BB4B8@306900ANEX2.global.avaya.com> 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 Cc: xcon@ietf.org 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: Mon, 26 Apr 2010 18:11:03 -0000 Hi Sean, here we go again ;-). See [SIMON] in-line. > [SEAN] The thing is if I am moderator of my conference and I want =20 > xcon-userid:pippozzo@example.com to join it, I could send > the above cmd and xcon-userid:pippozzo@example.com would be placed =20 > in it without having knowledge of the moderator passcode of > xcon-userid:pippozzo@example.com's existing conference? I think the =20 > cmd needs to have both passcodes... [SIMON] Let's say Alice is the moderator (on the conference control =20 plane) of a password-protected conference, "alice_conf_", and Bob is the new =20 conferencing client Alice wants to add to her conference. It is not =20 relevant to Alice whether Bob is involved in another conference or =20 not. If Alice wants Bob to join her conference, she has just to send =20 the following userRequest/create: * subject : username =3D alice, password =3D alice_personal_pwd * confUserID =3D xcon-userid:alice@example.com * confObjID =3D xcon:alice_conf_@example.com * operation =3D create * conference-password =3D alice_conf_pwd * userInfo =3D Now, let us suppose that Alice knows that Bob is currently involved in anoth= er password-protected conference, "conf_2_", and that she wants Bob to =20 leave that conference before joining her own conference. If Alice is =20 aware of the conf_2_ conference-password ("conf_2_pwd") and the =20 conferencing system allows she to perform this kind of action, Alice =20 can send the following userRequest/delete message before the =20 userRequest/create one: * subject : username =3D alice, password =3D alice_personal_pwd * confUserID =3D xcon-userid:alice@example.com * confObjID =3D xcon:conf_2_@example.com * operation =3D delete * conference-password =3D conf_2_pwd * userInfo =3D Does this clarify this issue? Or am I mistaking your concern? > [SEAN] How does the server know that the client wants the user to =20 > enter a sidebar as opposed to just deleting the user from the main =20 > conference? > * 2) userRequest/create on the sidebar > * 3) userRequest/delete from the sidebar > [SEAN] How does the server know that the client wants the user to =20 > join back in to the main conference as opposed to just deleting the =20 > user from the sidebar conference? [SIMON] Since CCMP is a state-less protocol, each operation is =20 independent from the others. Hence, the server doesn't care about =20 user's future actions when performing the requested operation. If you =20 want that only the main conference participants can share a private =20 sidebar conversation (leaving the main one) and then be allowed to =20 re-join the main conference, you can't leverage CCMP to implement this =20 kind of mechanism, but rather you can configure an appropriate policy =20 mechanism exploiting, for example, the allowed-users-list of the two =20 conferences (which is out of the scope of the protocol design). For =20 example, you can envisage that, when creating an internal sidebar, in =20 the sidebar allowed-users-list only the main conference participants =20 appear (i.e. they are the only ones who are allowed to join), and =20 that, even if a main conference user leaves the main conference, =20 his/her name remains on the main conference allowed-users-list in =20 order to accept that user if he/she wants to come back again (and also =20 to allow for his/her participation in a possible future internal =20 sidebar). > [SEAN] Lean and mean operations are a desirable goal but also we =20 > should try to limit the number of requests > A client has to send. The clone operation is a very quick way to get =20 > conferences created but I > Do believe adding the ability to overide params in the clone =20 > operation via the confInfo param enhances the > Clone operation [SIMON] OK. If you keep on stating this, it means you definitely need =20 such functionality ;-). I'll change the paragraph in question in the =20 very next version of the document (which will be uploaded as soon as =20 we converge on the other issues and collect some more feedback from =20 the WG...). 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 Tue Apr 27 03:11: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 AB7B43A68DA for ; Tue, 27 Apr 2010 03:11:48 -0700 (PDT) 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 rMT10WsWOLUL for ; Tue, 27 Apr 2010 03:11:47 -0700 (PDT) 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 015533A67F8 for ; Tue, 27 Apr 2010 03:11:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="186063799" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Apr 2010 06:11:18 -0400 X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="455281351" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.153]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Apr 2010 06:11:17 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 11:10:57 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71011BB5F7@306900ANEX2.global.avaya.com> In-Reply-To: <20100426201045.8x0hgw8rkkw488cs@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt Thread-Index: Acrla81R5loMyOpgQ+mWBS732veu/gAg/tig References: <4408C6EC74CC3D42824FD68FDA8E8F710115C2D0@306900ANEX2.global.avaya.com><20100426115834.lhvudl29s4kk8w40@webmail.unina.it><4408C6EC74CC3D42824FD68FDA8E8F71011BB4B8@306900ANEX2.global.avaya.com> <20100426201045.8x0hgw8rkkw488cs@webmail.unina.it> From: "Duddy, Sean (Sean)" To: Cc: xcon@ietf.org 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: Tue, 27 Apr 2010 10:11:48 -0000 Hi Simon, See below.=20 -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 26 April 2010 19:11 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: RE: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt Hi Sean, here we go again ;-). See [SIMON] in-line. > [SEAN] The thing is if I am moderator of my conference and I want =20 > xcon-userid:pippozzo@example.com to join it, I could send > the above cmd and xcon-userid:pippozzo@example.com would be placed =20 > in it without having knowledge of the moderator passcode of > xcon-userid:pippozzo@example.com's existing conference? I think the =20 > cmd needs to have both passcodes... [SIMON] Let's say Alice is the moderator (on the conference control plane) of a password-protected conference, "alice_conf_", and Bob is the new = conferencing client Alice wants to add to her conference. It is not = relevant to Alice whether Bob is involved in another conference or not. = If Alice wants Bob to join her conference, she has just to send the = following userRequest/create: * subject : username =3D alice, password =3D alice_personal_pwd * confUserID =3D xcon-userid:alice@example.com * confObjID =3D xcon:alice_conf_@example.com * operation =3D create * conference-password =3D alice_conf_pwd * userInfo =3D [SEAN] OK if Bob is not involved in another conference then there is no = issue Now, let us suppose that Alice knows that Bob is currently involved in = another password-protected conference, "conf_2_", and that she wants Bob = to leave that conference before joining her own conference. If Alice is = aware of the conf_2_ conference-password ("conf_2_pwd") and the = conferencing system allows she to perform this kind of action, Alice can = send the following userRequest/delete message before the = userRequest/create one: * subject : username =3D alice, password =3D alice_personal_pwd * confUserID =3D xcon-userid:alice@example.com * confObjID =3D xcon:conf_2_@example.com * operation =3D delete * conference-password =3D conf_2_pwd * userInfo =3D Does this clarify this issue? Or am I mistaking your concern? [SEAN] the issue here is that the delete will disconnect Bob's call and = then the create will restablish his call with the new conference. The behaviour I am looking for is that Bob get moved to another = conference without any disconnection and reconnection=20 > [SEAN] How does the server know that the client wants the user to =20 > enter a sidebar as opposed to just deleting the user from the main =20 > conference? > * 2) userRequest/create on the sidebar > * 3) userRequest/delete from the sidebar > [SEAN] How does the server know that the client wants the user to =20 > join back in to the main conference as opposed to just deleting the =20 > user from the sidebar conference? [SIMON] Since CCMP is a state-less protocol, each operation is = independent from the others. Hence, the server doesn't care about user's = future actions when performing the requested operation. If you want that = only the main conference participants can share a private sidebar = conversation (leaving the main one) and then be allowed to re-join the = main conference, you can't leverage CCMP to implement this kind of = mechanism, but rather you can configure an appropriate policy mechanism = exploiting, for example, the allowed-users-list of the two conferences = (which is out of the scope of the protocol design). For example, you can = envisage that, when creating an internal sidebar, in the sidebar = allowed-users-list only the main conference participants appear (i.e. = they are the only ones who are allowed to join), and that, even if a = main conference user leaves the main conference, his/her name remains on = the main conference allowed-users-list in order to accept that user if = he/she wants to come back again (and also to allow for his/her = participation in a possible future internal sidebar). [SEAN] I don't think this clears my issue up. My basic use case is I = want to move particpants from main conference to sidebar without = disconnection of their call and then back to the main conference again.=20 Your original call flow was:- * 1) userRequest/delete from the main conference * 2) userRequest/create on the sidebar * 3) userRequest/delete from the sidebar * 4) userRequest/create on the main conference The first delete will disconnect the user from the conferencing bridge = which is not what I want.=20 > [SEAN] Lean and mean operations are a desirable goal but also we =20 > should try to limit the number of requests A client has to send. The=20 > clone operation is a very quick way to get conferences created but I > Do believe adding the ability to overide params in the clone =20 > operation via the confInfo param enhances the Clone operation [SIMON] OK. If you keep on stating this, it means you definitely need = such functionality ;-). I'll change the paragraph in question in the = very next version of the document (which will be uploaded as soon as we = converge on the other issues and collect some more feedback from the = WG...). [SEAN] Thanks very much. 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 gonzalo.camarillo@ericsson.com Thu Apr 29 00:42:28 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 CA97E3A67EC for ; Thu, 29 Apr 2010 00:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.713 X-Spam-Level: X-Spam-Status: No, score=-104.713 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ayOFUOWRcYtN for ; Thu, 29 Apr 2010 00:42:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 97B7328C1BA for ; Thu, 29 Apr 2010 00:42:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-ef-4bd9384c3d65 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5D.32.23532.C4839DB4; Thu, 29 Apr 2010 09:42:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 09:42:04 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 09:42:03 +0200 Received: from [131.160.126.170] (rvi2-126-170.lmf.ericsson.se [131.160.126.170]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AC1EA2549; Thu, 29 Apr 2010 10:42:03 +0300 (EEST) Message-ID: <4BD9384B.60907@ericsson.com> Date: Thu, 29 Apr 2010 10:42:03 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "spromano@unina.it" References: <4B8FB489.8000206@ericsson.com> <20100414151452.8f69evq5ogw8gsks@webmail.unina.it> In-Reply-To: <20100414151452.8f69evq5ogw8gsks@webmail.unina.it> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2010 07:42:04.0029 (UTC) FILETIME=[75FB9AD0:01CAE76F] X-Brightmail-Tracker: AAAAAA== Cc: XCON Subject: Re: [XCON] Comments on 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: Thu, 29 Apr 2010 07:42:28 -0000 Hi Simon, thanks for taking into account all my comments on this and the ccmp draft. Cheers, Gonzalo On 14/04/2010 4:14 PM, spromano@unina.it wrote: > Dear Gonzalo, > > thank you for the helpful review! I have just uploaded a new version > of the call flows document, which takes into account all of the > comments you made, as well as some minor remarks made by Sean Duddy. > Please have a look at the current version of the draft and let us know > what is your feeling about it. > > Cheers, > > Simon > > Quoting Gonzalo Camarillo : > >> Hi, >> >> a few comments on the following document: >> >> http://www.ietf.org/id/draft-ietf-xcon-examples-03.txt >> >> This document provides an easy-to-read introduction to CCMP and a set of >> useful call flows for those intending to get an overview of the >> protocol. I have a few minor comments: >> >> Section 2 references RFC 2119. However, the intended status of this >> document is Informational. Besides, the document does not seem to use >> RFC 2119 normative language. That paragraph probably needs to removed. >> >> Section 3: >> >> "This document uses the same terminology as found in the referenced >> documents" >> >> Can we be a bit more precise and actually reference the documents we >> are talking about? >> >> Last paragraph of Section 4. For completness, it should also describe >> the contents of Section 10 (i.e., the lack of IANA considerations). >> >> Section 5: s/indipendently/independently/ >> >> Section 5.2 >> >> "[I-D.ietf-xcon-ccmp] presents several ways by which CCMP requests and >> responses can be transported" >> >> I may be mistaken but the CCMP spec does not seem to present different >> transports for the protocol. I understood CCMP supports different >> transports but the spec only describes the HTTP transport. We may want >> to rephrase that sentence so that it talks about CCMP potentially >> "supporting" different transport mechanisms instead. >> >> Also in Section 5.2: >> >> "...the Server would reply by means..." >> >> The term being used in the text seems to be ConfS, not Server. >> >> Section 5.3 describes the fact that the XCON notification mechanism is >> based on SIP as a drawback because one needs a SIP stack to use it. It >> would not present it as a drawback; simply as a fact. >> >> Also in Section 5.3: >> >> OLD: >> other protocols as XMPP >> >> NEW >> other protocols such as XMPP >> >> Section 7.2. The two first paragraphs talk about the relationship of >> muting at the media level and floor control. In the past, there has >> been some confusion around this. So, it may be worthwhile clarifying >> that floor control and policy control at the media level are two >> different things. You can have floor control that is not enforced in >> any way, or floor control that is enforced at the media level (i.e., >> the conference bridge will only accept your media if you have the >> floor). Adding a couple of sentences explaining this would be helpful, >> I think. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www.ietf.org/mailman/listinfo/xcon >> > > >