From alan@sipstation.com Tue Jan 5 10:24: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 5C89928C1AB for ; Tue, 5 Jan 2010 10:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 Mn9EJeEv4-jU for ; Tue, 5 Jan 2010 10:24:56 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A6C2C28C18C for ; Tue, 5 Jan 2010 10:24:56 -0800 (PST) Received: from 24-107-197-239.dhcp.stls.mo.charter.com ([24.107.197.239] helo=Alans-PowerBook-G4-17.local) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NSE5O-000ARq-3v for xcon@ietf.org; Tue, 05 Jan 2010 18:24:55 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.239 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19XL0VsXHZK72QxHd1kcxAufMzoXHL81Y8= Message-ID: <4B4383F4.2020004@sipstation.com> Date: Tue, 05 Jan 2010 12:24:52 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [XCON] WGLC of CCMP and Examples 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, 05 Jan 2010 18:24:57 -0000 All, This is to announce Working Group Last Call on the following documents: draft-ietf-xcon-ccmp-05 draft-ietf-xcon-examples-02 It is also a good time to look back at: draft-ietf-xcon-common-data-model-14 and make sure all three draft are aligned as they will be sent to the IESG at the same time. WGLC will conclude on Tuesday January 19, 2010. Please send comments to xcon@ietf.org. Thanks, Alan co-chair From yguo2@cisco.com Tue Jan 12 15:06: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 5B6FE3A68A2 for ; Tue, 12 Jan 2010 15:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.043 X-Spam-Level: X-Spam-Status: No, score=-7.043 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 F9D7lcx0-I1g for ; Tue, 12 Jan 2010 15:06:38 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 642303A67F3 for ; Tue, 12 Jan 2010 15:06:38 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroEAK6OTEurR7H+/2dsb2JhbACDXpdqpjWHBAGNb4Eogi9ZBIpJ X-IronPort-AV: E=Sophos;i="4.49,264,1262563200"; d="scan'208";a="232350879" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2010 23:06:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0CN6XYq009492; Tue, 12 Jan 2010 23:06:36 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 15:06:35 -0800 Received: from 128.107.102.131 ([128.107.102.131]) by xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Jan 2010 23:06:35 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 12 Jan 2010 15:06:34 -0800 From: yguo2 To: Message-ID: Thread-Topic: [XCON] Comments about draft-ietf-xcon-ccmp-04.txt Thread-Index: AcqT2+J2foMAruY0OEu/zt4NR2B0HQ== In-Reply-To: <20091221185339.3hmyxu8tcgg4c08c@webmail.unina.it> Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2010 23:06:35.0576 (UTC) FILETIME=[E366B380:01CA93DB] Cc: xcon@ietf.org Subject: Re: [XCON] Comments about draft-ietf-xcon-ccmp-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: Tue, 12 Jan 2010 23:06:39 -0000 Hi Simon, For 1) I don't think it is necessary to replicate the whole example in CCMP. It would be better if we can mention the example in CCMP and refer to the call flow document for more details. Thanks Yu On 09-12-21 上午9:53, "spromano@unina.it" wrote: > Hi Yu, > > see my answers in-line ([spromano]-prefixed). > >> 1 In section 7: A complete example of the CCMP in action >> Can we have a new example for scenario: >> Alice tries to mute another user Bob. > > [spromano] The mentioned example is contained in the call flows > document (which we are on the point of submitting in its latest > version), section 6.4, "Muting a party". I don't know if it is useful > to replicate it in the CCMP document. What is your opinion about that? > >> >> 2 If the conference system consists of general purpose conference room which >> is bound to any user, then how does CCMP work in this situation? >> Specifically, how would CCMP model the scenario: “room San Jose wants to >> invite room New York to a conference”? > > [spromano] CCMP does not envisage the possibility of "natively" > inviting a conference to another conference. What can be done is for a > user in a conference to retrieve the list of users in the other > conference (usersRequest/retrieve) and immediately thereafter issue a > usersRequest/update message aimed at modifying the allowed users list > of the first conference (by stating that the newly invited users must > be contacted in "dial-out" mode). > Alternatively, we might create a sidebar (which would be in all > respects a clone of the first conference) and invite all users of the > second conference as participants in it. > > Cheers, > > Simon > > From duddy@avaya.com Fri Jan 15 04:22:31 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 A249B3A6960; Fri, 15 Jan 2010 04:22:31 -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 WA3L41XW2jcd; Fri, 15 Jan 2010 04:22:30 -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 4FECF3A67B3; Fri, 15 Jan 2010 04:22:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,282,1262581200"; d="scan'208";a="200183350" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jan 2010 07:22:27 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.151]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jan 2010 07:22:26 -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: Fri, 15 Jan 2010 12:26:37 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A3F6D@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-examples-02.txt Thread-Index: AcqIhN+qAdpgBFVjTA6B3ofpc57XfQEzUDmgAiLjwyA= References: <20091229124502.4879A3A68EA@core3.amsl.com> From: "Duddy, Sean (Sean)" To: , Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-examples-02.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: Fri, 15 Jan 2010 12:22:31 -0000 I believe these drafts are nearing completion, so could I get some responses to these questions please?=20 -----Original Message----- From: Duddy, Sean (Sean)=20 Sent: 04 January 2010 15:27 To: 'Internet-Drafts@ietf.org'; i-d-announce@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] I-D Action:draft-ietf-xcon-examples-02.txt Hi All, Some questions/issues on this draft:- General:- In section 6.4(Muting a party), an update user request is sent specifying the status value. None of the other elements are present in this update request. I assume their absence does not imply that the server set null values for these fields in its data model?=20 e.g. if the endpoint been muted had a value, this would be untouched during the update. This question would apply to any update question. 6.1. "1. Upon receipt of the userRequest from "Alice" to be added to "Bob's" conference (i.e., an "update" operation on "Bob's"...." There is no update operation for this scenario, it is a create user operation on the conference. 6.3 Adding a party How can an 'adhoc' user be added to a conference? e.g. I want to add someone to the conference but I do not want their details to be created in the conferencing server for future use. =09 Sean =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 29 December 2009 12:45 To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-examples-02.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-02.txt Pages : 80 Date : 2009-12-29 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 2, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-02.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 Fri Jan 15 04:23:33 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 6BAD73A6960 for ; Fri, 15 Jan 2010 04:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 I+HSNnHlZoh9 for ; Fri, 15 Jan 2010 04:23:32 -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 1A8893A67B3 for ; Fri, 15 Jan 2010 04:23:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,282,1262581200"; d="scan'208";a="172324593" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jan 2010 07:23:25 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.151]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jan 2010 07:23:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jan 2010 12:27:36 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A3F6E@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Thread-Index: AcqCZM8SuU9lU4KtTDGTJwZFoyohSgK9oZcAAAOflLACHQp90A== From: "Duddy, Sean (Sean)" To: Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-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: Fri, 15 Jan 2010 12:23:33 -0000 Hi Simon, I believe these drafts are nearing completion, so could I get some = responses to these issue please? =20 -----Original Message----- From: Duddy, Sean (Sean)=20 Sent: 04 January 2010 18:23 To: 'spromano@unina.it' Cc: xcon@ietf.org Subject: RE: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Hi Simon,=20 see comments below starting with [SEAN] -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it] Sent: 21 December 2009 17:41 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Hi Sean, thank you for your comments. Please find my answers in-line (with a = prefix of [spromano]). BTW, we are going to submit a fresh version of = the CCMP draft in the next few days. > General: > The new element needs to be expanded to=20 > indicate its type. > E.g. a conference could have a moderator and conferee password and=20 > the ccmp client would > need to know which is which. [spromano] I take this as a suggestion to modify the data model, rather = than the CCMP, since in the draft we are just referring to [I D.ietf = xcon common data model]. This said, I personally think that you are touching again the important = issue of defining a role-based access control policy system associated = with the management of conferences, users and their respective roles. I = keep on thinking that such system is somehow "orthogonal" to the = framework itself. Let me once again self-reference an old post about this topic: http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html When we are eventually done with the last issues related to CCMP, I will = be glad to work on the above proposal, if there is some interest in = carrying it out. [SEAN]: Actually you are right this is a data model issue, however since = we have started the question we might as well finish it here.... I don't think this has anything to do with RBAC etc. The new = field was introduced to specify a password = for a conference. My question is:- If a conference has two passwords, = one for moderator and one for particpant, how would a (CCMP) client know = which one is the moderator and which one is the conferee? > 6.1 CCMP Request Message Type > confUserID/password > The purpose of these elements is not clear. The draft states that the = > password should contain > the value of the xcon:conference-password element. [spromano] ?confUserId? is used to know who is asking to perform a = certain operation (e.g. for AAA purposes). When such information is = missing in a "userRequest/create" operation, this means that the request = itself is a join operation PLUS creation of an xcon-userid (and related = association tree on the server's side: sip-uri, xcon-uri, role, etc.) = associated with the sender. This should become clearer in the general sample call flows contained in = the draft, as well as in the detailed flows presented in the companion = XCON call flows draft. As to the password, see the answer to your previous comment. > > Section 6.3.6 states that the XCON-USERID could be an administrator=20 > or some other non conference participating user > of the ccmp server. In this case, the password field in the request=20 > would be that of the administrator and would have nothing to > do with the conferences he/she is about to provision. > > So to summarise: The request password field may be a conference=20 > password but it also may be some other piece of info to authenticate > the client issuing the command. [spromano] The "password" field is optional. Again, we look at it as = being strictly related to the conference, as per the = element of the data model. We have not taken into = account the case of a non-participating administrator who is willing to = use such field to enter the conferencing system and carry out CCMP-based = operations. Stated in different terms, we did not face the issue of = authenticating the system administrator via a field other than his own = xcon-userid. I would ask other people in the WG to express their opinion on this = topic. [SEAN] I think we have to consider this. It is quite likely that a CCMP = server could have an administrator provisioned, that has rights to = create/change any conference on the system.=20 > > 6.3.2. confsRequest and confsResponse > A filter mechanism needs to be specified here to allow clients only=20 > retreieve a subset of conferences based on search crieteria. > e.g. A ccmp client might only be interested in conferences pertaining = > to a certain user or active conferences between a date range etc. [spromano] Right! We already proposed to add filters to both = confsRequest and blueprintsRequest messages. Our idea would be the = following (you'll find it in the upcoming versions of the draft), with = reference, e.g. to the former message: As you can see, we propose to add an optional "xpathFilter" element (of = a generic "xs:string" type) to the message, in order to allow the server = to appropriately filter out unwanted information before sending back to = the client the list of conferences. Example --> retrieve just registered conferences: xpathFilter=3D"/info:conference-info[info:conference-state/info:active=3D= 'false']"; What is your feeling about such proposal? Do you think it does the job? = Or should we go for a finer-grained definition of the new element (which = might be bound, for example, to sharply represent an xpath query rather = than a generic string)? [SEAN] XPATH definietly will work and covers all filter possibilities. = However, should the draft state that a server could only support a = limited,documented set of xpath queries? Support for a complete range of xpath queries would/could be difficult = to implement .... > > 6.3.2 Related to the 6.1 issues, if an administrator wants to = retrieve > a user belonging to a conference, where in the userRequest message > is the user XCON ID specified? It looks like it is specified=20 > in confUserID which would be wrong in this case.... [spromano] The xcon-userid of the target user is contained inside the = "entity" attribute of the userRequest/retrieve message. Example: Alice is administrator and wants to retrieve Bob's info, with = Bob being a participant in conference 8977777. Alice sends the following = message via the CCMP: = xcon-userid:alice@example.com xcon:8977777@example.com retrieve Inside the response, ?confUserId? contains = ?xcon-userid:alice@example.com?, whereas the ?userInfo? parameter = carries back Bob's information. [SEAN]Well for AAA purposes, the administrator(Alice) would probably = need to supply a password also in the request. This password would be = Alice's admin password. However the CCMP definition for the password field is:- password: An optional parameter that MUST be inserted in all requests whose target conference object is password-protected (as per the element in [I-D.ietf-xcon-common-data-model]). So I am still confused about the password parameter defined in the CCMP = draft. > > 6.3.4. confRequest and confResponse > This is a general question. If one develops a CCMP based provisioning = > client to simply provision conferences on the server, > they are not interested in the conference runtime parameters of=20 > conferences like the entities. Not a big deal for the client, > they can simply ignore this info, but it is a significent performance = > hit for the CCMP server to provide up to date conference runtime > info to clients... I think we need some mechanism to avoid this=20 > overhead for clients that do not need this info. [spromano] If one wants to retrieve general information about available = conferences, he can issue a confsRequest message, whose response will = contain high-level information (in particular, all that can be inserted = in a "uri-type" element -- display-text, uri, purpose, etc. --). A = drill-down query can be issued by sending a confRequest message = associated with a specific conference object. In principle, the entire = conference document is sent back to the client, even though the choice = of what kind of information to provide (e.g. users list, passwords, = etc.) is completely implementation-dependent. The only requirement is = for the server to send back an xml element compliant with the = "conference-type" element of the data model. Once again, a policy-based = approach might be put into place to properly identify/discriminate "who = is trying to do what" and (re)act accordingly. [SEAN] My concern here is that this introduces ambiguity. If a = conference-type element is returned with no element, does that = imply the conference does not have any users Or the server didn't bother = populating this element? Finally, if a user wants to retrieve fragments of a conference object = (e.g. info about a certain user, all users, sidebars, etc), she can = exploit the ad-hoc conceived messages made available by the protocol. =20 As you will have noticed, when deciding what messages to define for the = CCMP, we tried to strike the balance between granularity of the protocol = and its complexity. > > 10 HTTP Transport > Link 'Section 7.2.1.' does not exist > > Sean [spromano] Right. Thank you for pointing this out. Cheers, Simon > > > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf=20 > Of Internet-Drafts@ietf.org > Sent: 12 November 2009 02:00 > To: i-d-announce@ietf.org > Cc: xcon@ietf.org > Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Centralized Conferencing Working=20 > Group of the IETF. > > > Title : Centralized Conferencing Manipulation Protocol > Author(s) : M. Barnes, et al. > Filename : draft-ietf-xcon-ccmp-04.txt > Pages : 98 > Date : 2009-11-11 > > The Centralized Conferencing Manipulation Protocol (CCMP) can create,=20 > retrieve, change and delete objects describing a centralized=20 > conference, such as state and capabilities of the conference,=20 > participants, and their roles. The conference information is=20 > contained in XML documents and fragments conforming to the centralized = > conferencing data model schema. Even though the goal of the CCMP is=20 > to appropriately manage conference state, the mechanisms upon which=20 > the protocol itself is built are based on a state-less=20 > request/response paradigm. Conferencing clients send requests to=20 > conference servers, which respond to the client with the conference = information. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the=20 > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering Task = > Force (IETF), its areas, and its working groups. Note that other=20 > groups may also distribute working documents as Internet- Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months=20 > and may be updated, replaced, or obsoleted by other documents at any=20 > time. It is inappropriate to use Internet-Drafts as reference=20 > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at=20 > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at=20 > http://www.ietf.org/shadow.html. > This Internet-Draft will expire on May 16, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the=20 > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal=20 > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of=20 > publication of this document. Please review these documents=20 > carefully, as they describe your rights and restrictions with respect=20 > to this document. Code Components extracted from this document must=20 > include Simplified BSD License text as described in Section 4.e of the = > Trust Legal Provisions and are provided without warranty as described=20 > in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > _______________________________________________ > 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 lorenzo@meetecho.com Sat Jan 16 06:23:14 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 CCD393A6908 for ; Sat, 16 Jan 2010 06:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, UNPARSEABLE_RELAY=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 u8WM5h3exE58 for ; Sat, 16 Jan 2010 06:23:13 -0800 (PST) Received: from smtp1.aruba.it (smtp2.aruba.it [62.149.128.201]) by core3.amsl.com (Postfix) with SMTP id D6EC03A68A7 for ; Sat, 16 Jan 2010 06:23:12 -0800 (PST) Received: (qmail 3528 invoked by uid 89); 16 Jan 2010 14:23:06 -0000 Received: from unknown (HELO webmaildh5.ad.aruba.it) (lorenzo@meetecho.com@10.10.10.94) by smtp1.aruba.it with SMTP; 16 Jan 2010 14:23:06 -0000 Received: from 79.41.54.99 by HTTP Sender: lorenzo@meetecho.com From: "Lorenzo Miniero" To: "Duddy, Sean (Sean)" X-Mailer: Quality Web Email v3.1s X-Originating-IP: 79.41.54.99 Date: Sat, 16 Jan 2010 15:23:07 +0100 Message-id: <4b51cbcb.114.2ab6.2031474943@webmaildh5.ad.aruba.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: smtp1.aruba.it 1.6.2 0/1000/N Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-examples-02.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: Sat, 16 Jan 2010 14:23:15 -0000 Hi Sean, I apogize for the late reply, but I've just checked in my old mail and could find no trace of your 4th January post. Maybe it got lost? Here's a few comments inline ([LM]). ----- Original Message ----- From: "Duddy, Sean (Sean)" To: , Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-examples-02.txt Date: Fri, 15 Jan 2010 12:26:37 -0000 > I believe these drafts are nearing completion, so could I > get some responses to these questions please? > > -----Original Message----- > From: Duddy, Sean (Sean) > Sent: 04 January 2010 15:27 > To: 'Internet-Drafts@ietf.org'; i-d-announce@ietf.org > Cc: xcon@ietf.org > Subject: RE: [XCON] I-D > Action:draft-ietf-xcon-examples-02.txt > > Hi All, > > Some questions/issues on this draft:- > > General:- > In section 6.4(Muting a party), an update user request > is sent specifying the status value. > None of the other elements are present in this > update request. I assume their absence does not imply that > the server set null values for these fields in its data > model? e.g. if the endpoint been muted had a > value, this would be untouched during the > update. This question would apply to any update question. > [LM] You're right in assuming that not specifying something in an update does not mean that it is removed from the conference description. An update only modifies what is included, and leaves the rest untouched. We'll add some text (maybe at the beginning of the doc, before the call flows) to better clarify these generic aspects of the protocol, so that it doesn't confuse people reading it. > 6.1. > "1. Upon receipt of the userRequest from "Alice" to be > added to > "Bob's" conference (i.e., an "update" operation on > "Bob's"...." There is no update operation for this > scenario, it is a create user operation on the conference. > [LM] It's not an update operation, in fact. What we meant is that the conference info is updated with the details on the new user, Bob. So, it was just a poor choice of words, we'll correct this in the next version of the doc. > 6.3 Adding a party > How can an 'adhoc' user be added to a conference? e.g. > I want to add someone to the conference but I do not want > their details to be created in the > conferencing server for future use. > [LM] This is a good point, and it may be useful to add a scenario for that in the doc as well. The CCMP doc explains how to do this in Section 6.3.6, at the end of page 34. It basically consists in an userRequest with no entity attribute in the userInfo: the conferencing system takes care of creating both this entity and a valid XCON user ID. Thanks for your feedback, Lorenzo > Sean > > > > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: 29 December 2009 12:45 > To: i-d-announce@ietf.org > Cc: xcon@ietf.org > Subject: [XCON] I-D Action:draft-ietf-xcon-examples-02.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-02.txt > Pages : 80 > Date : 2009-12-29 > > 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. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full > conformance with the provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet > Engineering Task Force (IETF), its areas, and its working > groups. Note that other groups may also distribute > working documents as Internet- Drafts. > > Internet-Drafts are draft documents valid for a maximum of > six months and may be updated, replaced, or obsoleted by > other documents at any time. It is inappropriate to use > Internet-Drafts as reference material or to cite them > other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be > accessed at http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on July 2, 2010.Copyright > Notice > > Copyright (c) 2009 IETF Trust and the persons identified > as the document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's > Legal Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the > date of publication of this document. Please review these > documents carefully, as they describe your rights and > restrictions with respect to this document. Code > Components extracted from this document must include > Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without > warranty as described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-02.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. > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon Lorenzo Miniero http://www.meetecho.com From alan.b.johnston@gmail.com Sat Jan 16 14:36: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 8FECF3A6805 for ; Sat, 16 Jan 2010 14:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 OkyMcwAhaifb for ; Sat, 16 Jan 2010 14:36:58 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 17A8A3A67AE for ; Sat, 16 Jan 2010 14:36:58 -0800 (PST) Received: from 24-107-197-239.dhcp.stls.mo.charter.com ([24.107.197.239] helo=Alans-PowerBook-G4-17.local) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NWHGI-000BrG-2M for xcon@ietf.org; Sat, 16 Jan 2010 22:36:54 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.239 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+JcFTvnS2X8InE/RnynKwhTDF2fpEXTpk= Message-ID: <4B523F84.4000407@gmail.com> Date: Sat, 16 Jan 2010 16:36:52 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 16 Jan 2010 22:36:59 -0000 I have no technical issues in the draft. All these comments are editorial in nature. Overall, I am very happy with the draft and think it is ready to progress. Good job to everyone who has worked so hard over the years on this, our core XCON protocol. - Alan - (as individual) Abstract: It would be nice if the Abstract mentions that this document defines a new sub-URN, an XML schema, a MIME type, and DNS NAPTR extensions. The phrase "the CCMP" appears in a lot of places. Usually, we only use "the" when spelling out the whole name (i.e. "the Centralized Conferencing Manipulation Protocol") - otherwise, drop the article and just say "CCMP". 1. Introduction: "Operations on conferences include adding and removing participants, changing their roles, as well as adding and removing media streams and associated end points." change to: "Operations on conferences include adding and removing participants, changing the roles of participants, as well as adding and removing media streams and associated end points." 4.1 Conference Objects: It would be nice to reference the data model when the XCON-URI is first mentioned so the reader knows where this is defined. 4.2 Conference Users "provides a mean" -> "provides a means" 5. Protocol Overview: This section is called the overview, but it is actually the formal definition of the protocol, as 5.1 has the first normative statement. I'm OK with keeping the section name, but it might be worth saying this is where the protocol is normatively defined. "state-less" -> "stateless" 6.1 CCMP Request Message Type "This is specialization" -> "This is a specialization" Table 1: This table needs a few minor formatting. One heading reads "-Request Type" which I presume should be just "Request Type" Also the element "Gets sidebars-by-val element" and "Gets sidebars-by-ref element" has some weird formatting. 6.3.6. userRequest and userResponse "like creating a conference" -> "such as creating a conference" The example: " Request fields: confUserID=null; confObjID=confXYZ; operation=create; userInfo= ... Response fields (in case of success): confUserID=user345; confObjID=confXYZ; operation=create; response-code=success; userInfo=null; //or the entire userInfo object" I'm not sure why this is not in XML - is there a reason? If so, I'd suggest explaining. If not, I'd suggest making it XML like the rest of the examples. Table 2: This table also has a few formatting nits. The wrapping of single characters ("d" and "t") looks like it could be avoided. The item with "3rd party invite with third user entity" has some very confusing formatting - I'm also not sure I know exactly that that means. 7. A complete example of CCMP in action It might be worth stating that this example is non-normative. 7.1 " Simple Room: conference room with public access, where only audio is available, more users can talk at the same time and the requests for the AudioFloor are automatically accepted. " should "more users" be "multiple users"? If not, make it clear what is meant. 7.5 " " Can a REFER be sent to a tel URI? Or am I mistaking the meaning here? 7.6 "Notice that such element includes information about the user's Address of Records, as well as her current end-point. " Do you really mean AORs or do you just mean AOR? Does having a single user have multiple AORs have any security/authentication issues? 8. Locating a Conference Control Server This section probably should reference RFC 3958 somewhere the first time U-NAPTR is mentioned. 13.1 URN Sub-Namespace Registration Should the URN have double double quotes? 15. Changes Since Last Version I'd suggest deleting this in the next version. From alan.b.johnston@gmail.com Mon Jan 18 20:03:00 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 CF1A43A6A27 for ; Mon, 18 Jan 2010 20:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, 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 slMnov95tJxA for ; Mon, 18 Jan 2010 20:03:00 -0800 (PST) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.223.174]) by core3.amsl.com (Postfix) with ESMTP id ED5E23A69C3 for ; Mon, 18 Jan 2010 20:02:59 -0800 (PST) Received: by iwn4 with SMTP id 4so2617139iwn.31 for ; Mon, 18 Jan 2010 20:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Nmj9N+exULyMKvxvmO1cooIJUP/YJWWFqDbqAHKWRDo=; b=Zx7FjqsMexAqLLllR4lURopHsldE1Z3jf6Cq9uDmyvM+aajlWJgVtZKzWjV2Aje/LV NERQE8J5M5/QDtj8ARsTpxdFMGTc1tsWRrupdRLA4mCdasWb3DcX7ohNzogKzdSN5BFr cAWmF8Q+2NCwCTS2leWafaDAG8kLvkrWeNVfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=hFQs/fYM3pzPKBpFJ5Od9JRyLtNqae2r5obFeu3xOy1ZCtRA+FNxBf0rt8EqovBDCf n/ljhgyNJAfZL75YQr1xnXVpb6tMTJOPCeT9BRrh9BiDw3k2GfzOZb8yNSdwISaZQ+Bf /dlnnQiUcIQC8bWf7pS3P2chP62R6PhH8AIpI= Received: by 10.231.154.197 with SMTP id p5mr1177658ibw.28.1263873773071; Mon, 18 Jan 2010 20:02:53 -0800 (PST) Received: from Alans-PowerBook-G4-17.local (24-107-197-239.dhcp.stls.mo.charter.com [24.107.197.239]) by mx.google.com with ESMTPS id 22sm5003734iwn.12.2010.01.18.20.02.51 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 20:02:52 -0800 (PST) Message-ID: <4B552EEA.60202@gmail.com> Date: Mon, 18 Jan 2010 22:02:50 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [XCON] CCMP Call Flows 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, 19 Jan 2010 04:03:00 -0000 I found no technical issues in the CCMP Call Flows document. There appears to be some missing content in Sections 7.2 and Section 8 where it says "Details/Text/Examples to be added" We need to quickly add this information, remove these notes, or delete these sections from the document. A few editorial comments and nits are listed below. - Alan - (as individual) Section 4. Overview "a simple guide on the use" -> "a simple guide for the use" Section 5. Conference Creation "Clients that are not XCON-aware may join the conference" -> "Clients that are not XCON-aware can join the conference" Figure 2. You need to define and explain the elements in the call flow: CMCC1, CMCC2, CMCCx, CONFS, and MS. I can guess what they are, but we should be explicit. Figure 6. Don't need quotes around Alice, i.e. "Alice" -> Alice Figure 8. Since this a long long figure, you should start with a fresh page break. Page 20: "Any blueprint that "Alice" is authorized to use are returned" -> "Any blueprints that Alice is authorized to use are returned" Section 11. Remove. Section 13.1 Normative References. I think the whole document is informative, so there aren't any normative references, or a need to reference RFC 2119. From duddy@avaya.com Wed Jan 20 15:27:54 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 28BD428C0E8 for ; Wed, 20 Jan 2010 15:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 3AbEhkGbMRKN for ; Wed, 20 Jan 2010 15:27:53 -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 5841C3A6877 for ; Wed, 20 Jan 2010 15:27:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,313,1262581200"; d="scan'208";a="201209056" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Jan 2010 18:27:48 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Jan 2010 18:27:18 -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, 20 Jan 2010 23:26:03 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A44D1@306900ANEX2.global.avaya.com> In-Reply-To: <4B523F84.4000407@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvA 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, 20 Jan 2010 23:27:54 -0000 Hi All, Some more comments:- 1. What is the expected behaviour of a CCMP server when a client attempts to create a conference via implicit cloning, and the supplied xcon URI (via the entity attribute) already exists on the server side? I am thinking we should have another ResponseCode of 'objectAlreadyExists'. BTW: In the CCMP examples - "Create Basic Conference from user provided conference-info", the xml is missing the mandatory entity attribute. I would imagine most CCMP servers would generate the XCON URI, so do we need to define a default XCON URI to indicate to the server that it must generate one? 2. The 'blueprintInfo' element needs to have a minOccurs=3D"0" to allow for responses that may not have a info:conference-type element e.g. for blueprint delete, or for blueprint operations that have returned in error. The same applies for 'confInfo' element. There are probably other response elements that require this change also... Regards Sean From duddy@avaya.com Thu Jan 21 02:36: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 B851628C138 for ; Thu, 21 Jan 2010 02:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 bHMuDQnS044n for ; Thu, 21 Jan 2010 02:36:57 -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 9AE8B28C137 for ; Thu, 21 Jan 2010 02:36:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,316,1262581200"; d="scan'208";a="173256207" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Jan 2010 05:36:51 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Jan 2010 05:36:50 -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, 21 Jan 2010 10:35:51 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A4505@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+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMA= 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, 21 Jan 2010 10:36:57 -0000 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? What if I want to clone an existing conference? Would the element be returned in the confResponse? 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 ? 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 ... Regards Sean From duddy@avaya.com Fri Jan 22 04:17:14 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 589C33A68D5 for ; Fri, 22 Jan 2010 04:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 AISJI6SeTsP2 for ; Fri, 22 Jan 2010 04:17:13 -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 341FB3A68B8 for ; Fri, 22 Jan 2010 04:17:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,323,1262581200"; d="scan'208";a="173472936" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Jan 2010 07:17:06 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jan 2010 07:16:50 -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: Fri, 22 Jan 2010 12:18:11 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A466F@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-common-data-model-14 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYA== References: <4B523F84.4000407@gmail.com> From: "Duddy, Sean (Sean)" To: Subject: [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: Fri, 22 Jan 2010 12:17:14 -0000 Minor change: In section 4, there is an '*' after the element indicating that this element has been defined in rfc4575.=20 This '*' should be removed because is a new extension defined in this model... Sean From duddy@avaya.com Fri Jan 22 04:19:10 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 AC4293A67E9 for ; Fri, 22 Jan 2010 04:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 sY7ZiErNnfkM for ; Fri, 22 Jan 2010 04:19:09 -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 AA8A03A6895 for ; Fri, 22 Jan 2010 04:19:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,323,1262581200"; d="scan'208";a="201545865" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jan 2010 07:19:03 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jan 2010 07:18:23 -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: Fri, 22 Jan 2010 12:19:49 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A4671@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-examples-02 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYAAAI76g References: <4B523F84.4000407@gmail.com> From: "Duddy, Sean (Sean)" To: Subject: [XCON] Comments on draft-ietf-xcon-examples-02 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, 22 Jan 2010 12:19:10 -0000 Hi, This docoument should have an example on how the element gets populated... Sean From duddy@avaya.com Fri Jan 22 07:43: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 C59BC3A681D for ; Fri, 22 Jan 2010 07:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rDOS9ipoHcTH for ; Fri, 22 Jan 2010 07:43:25 -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 0390F3A6812 for ; Fri, 22 Jan 2010 07:43:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,324,1262581200"; d="scan'208";a="201594050" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jan 2010 10:43:20 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jan 2010 10:43:19 -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: Fri, 22 Jan 2010 15:47:41 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A46F5@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-common-data-model-14 Thread-Index: AcqW/G0E9+UQFKleQNaCH3LL0cPj4ADJxqvAABf3IMAANkTXYAAHYHPA References: <4B523F84.4000407@gmail.com> From: "Duddy, Sean (Sean)" To: Subject: [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: Fri, 22 Jan 2010 15:43:25 -0000 Hi, =09 The elements Have the wrong type, they should have type "xs:anyURI" Sean From spromano@unina.it Mon Jan 25 09:30:54 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 3A1063A6857 for ; Mon, 25 Jan 2010 09:30:54 -0800 (PST) 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 Dt9eNhNSCFBv for ; Mon, 25 Jan 2010 09:30:53 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 2473B3A6851 for ; Mon, 25 Jan 2010 09:30:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0PHUr76007733; Mon, 25 Jan 2010 18:30:53 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 25 Jan 2010 18:30:53 +0100 Message-ID: <20100125183053.ztrf0b7m74g0wsss@webmail.unina.it> Date: Mon, 25 Jan 2010 18:30:53 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4408C6EC74CC3D42824FD68FDA8E8F71010716F2@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010716F2@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-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: Mon, 25 Jan 2010 17:30:54 -0000 Hi Sean, sorry for the delay in answering your comments. Please find inline our =20 answers to your new questions ([spromano] prepended). As to the issues associated with the "" field: > [SEAN]: Actually you are right this is a data model issue, however =20 > since we have started the question we might as well finish it here.... > I don't think this has anything to do with RBAC etc. The new =20 > field was introduced to specify a =20 > password for a conference. My question is:- If a conference has two =20 > passwords, one for moderator and one for particpant, how would a =20 > (CCMP) client know which one is the moderator and which one is the =20 > conferee? [spromano] As I said, in the data model such scenario is not envisaged =20 (i.e. there are no role-related passwords per conference object). I =20 think we should discuss this with Oscar and the other authors of the =20 data model if you see a need for this. As to the "filters" issue: > [SEAN] XPATH definietly will work and covers all filter =20 > possibilities. However, should the draft state that a server could =20 > only support a limited,documented set of xpath queries? > Support for a complete range of xpath queries would/could be =20 > difficult to implement .... [spromano] Yes. I think we should definitely take your advice. A =20 minimal set of xpath queries should be considered as mandatory for any =20 CCMP-compliant server. We were thinking of things like "conference =20 state" (active, registered, etc.), conference participants, =20 conference media (info about all media involved in a conference), and =20 the like. Do you have any other clue on this? Finally, as to the "ambiguity" issue: > [SEAN] My concern here is that this introduces ambiguity. If a =20 > conference-type element is returned with no element, does =20 > that imply the conference does not have any users Or the server =20 > didn't bother populating this element? [spromano] What I meant here was that, in general, a conference server =20 should return to a client the "most complete" set of information it =20 has available, i.e. all data requested by the client and for which the =20 client itself holds an access right. This means that, in the absence =20 of server-side policies, each and every query would be answered with =20 the complete conference document. Cheers, Simon P.S. More mails are following, related to your further comments... --=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 rbarnes@bbn.com Mon Jan 25 09:38: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 5DC8E3A6851 for ; Mon, 25 Jan 2010 09:38:13 -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 WTzR0OP8n3Yv for ; Mon, 25 Jan 2010 09:38:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7B3AB3A6774 for ; Mon, 25 Jan 2010 09:38:12 -0800 (PST) Received: from ros-dhcp192-1-51-97.bbn.com ([192.1.51.97]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NZStG-0006f5-CG; Mon, 25 Jan 2010 12:38:18 -0500 Message-Id: <707BE072-7C57-46EB-AE54-A8843E3D87E4@bbn.com> From: "Richard L. Barnes" To: spromano@unina.it In-Reply-To: <20100125183053.ztrf0b7m74g0wsss@webmail.unina.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Jan 2010 12:38:17 -0500 References: <4408C6EC74CC3D42824FD68FDA8E8F71010716F2@306900ANEX2.global.avaya.com> <20100125183053.ztrf0b7m74g0wsss@webmail.unina.it> X-Mailer: Apple Mail (2.936) Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-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: Mon, 25 Jan 2010 17:38:13 -0000 >> [SEAN] XPATH definietly will work and covers all filter >> possibilities. However, should the draft state that a server could >> only support a limited,documented set of xpath queries? >> Support for a complete range of xpath queries would/could be >> difficult to implement .... > > [spromano] Yes. I think we should definitely take your advice. A > minimal set of xpath queries should be considered as mandatory for > any CCMP-compliant server. We were thinking of things like > "conference state" (active, registered, etc.), conference > participants, conference media (info about all media involved in a > conference), and the like. Do you have any other clue on this? 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 From spromano@unina.it Mon Jan 25 10:29:26 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 1501F28C0ED for ; Mon, 25 Jan 2010 10:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.788 X-Spam-Level: * X-Spam-Status: No, score=1.788 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 XlJfhhZfofZd for ; Mon, 25 Jan 2010 10:29:25 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id CDFF728C0CE for ; Mon, 25 Jan 2010 10:29:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0PITShj018640; Mon, 25 Jan 2010 19:29:28 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 25 Jan 2010 19:29:28 +0100 Message-ID: <20100125192928.99xxw9naf48ocs08@webmail.unina.it> Date: Mon, 25 Jan 2010 19:29:28 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A44D1@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A44D1@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] 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: Mon, 25 Jan 2010 18:29:26 -0000 Hi again, Sean, > Hi All, > =09Some more comments:- > > 1. What is the expected behaviour of a CCMP server when a client > attempts to create a conference via implicit cloning, and the supplied > xcon URI (via the entity attribute) already exists on the server side? I > am thinking we should have another ResponseCode of > 'objectAlreadyExists'. > BTW: In the CCMP examples - "Create Basic Conference from user provided > conference-info", the xml is missing the mandatory entity attribute. > > I would imagine most CCMP servers would generate the XCON URI, so do we > need to define a default XCON URI to indicate to the server that it must > generate one? > [spromano] Actually, you are right on this and you are raising here a =20 general issue, concerning all cases in which the client provides =20 information to the server in the form of a conference document (or =20 part of it). We did not take into account the fact that there are some =20 fields in the data model which are required (e.g. "entity" in =20 "conference-type" or in "conference-medium-type", "id" in =20 "media-type", etc.). This is due to the fact that the original data =20 model in RFC4575 has been conceived for sending information FROM a =20 conference server TO a conference client, while CCMP has been devised =20 also with the opposite hypothesis in mind (information flows also =20 along the direction FROM client TO server). Hence, we should =20 definitely modify our document by introducing a sort of "wildcard" =20 value for the above fields in all cases where they cannot be populated =20 by the client since they have not been created yet. As an example, in the mentioned case of the "implicit cloning" of a =20 conference (as in par. 5.2 of draft-ietf-xcon-examples-02), we should =20 modify the call flow as follows: ********* CURRENT VERSION ********* xcon-userid:Alice@example.com create [......] ******** END CURRENT VERSION ******* ******* UPDATED VERSION ************ xcon-userid:Alice@example.com create [......] ******** END UPDATED VERSION ******************** The difference between the two versions resides just in the use of a =20 "CREATE" wildcard value for the mandatory "entity" attribute. The same solution should be applied to all of the above mentioned cases. Do you think this is the right approach? In such case, we'll modify =20 both the CCMP and the call flows drafts. > 2. The 'blueprintInfo' element needs to have a minOccurs=3D"0" to allow > for responses that may not have a info:conference-type element e.g. for > blueprint delete, or for blueprint operations that have returned in > error. > The same applies for 'confInfo' element. There are probably other > response elements that require this change also... [spromano] Right. We'll check all of them. 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 spromano@unina.it Mon Jan 25 10:30:37 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 BC4A43A683D for ; Mon, 25 Jan 2010 10:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.835 X-Spam-Level: * X-Spam-Status: No, score=1.835 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 HjxwsucyUiDz for ; Mon, 25 Jan 2010 10:30:37 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id B2BDB3A67F0 for ; Mon, 25 Jan 2010 10:30:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0PIUdo9018868; Mon, 25 Jan 2010 19:30:39 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 25 Jan 2010 19:30:39 +0100 Message-ID: <20100125193039.z1q12v0d2ck0c8cg@webmail.unina.it> Date: Mon, 25 Jan 2010 19:30:39 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A4671@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A4671@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] Comments on draft-ietf-xcon-examples-02 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, 25 Jan 2010 18:30:37 -0000 Hi again :-), > Hi, > =09This docoument should have an example on how the > element gets populated... ...we'll work on it. We'll try and provide a nice example. 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 Jan 25 11:03:49 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 02C203A6834 for ; Mon, 25 Jan 2010 11:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.48 X-Spam-Level: * X-Spam-Status: No, score=1.48 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_20=-0.74, 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 dMOEP-zd0Kj1 for ; Mon, 25 Jan 2010 11:03:48 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id C774A3A679C for ; Mon, 25 Jan 2010 11:03:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0PJ3mD2023958; Mon, 25 Jan 2010 20:03:48 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 25 Jan 2010 20:03:48 +0100 Message-ID: <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> Date: Mon, 25 Jan 2010 20:03:48 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4B523F84.4000407@gmail.com> <4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A4505@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] 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: Mon, 25 Jan 2010 19:03:49 -0000 Hi Sean, > Hi All, > =09I 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 =20 scenario in which I can clone a conference by issuing a =20 confRequest/create message containing a conference document which =20 explicitely states its will of being created as a clone of an existing =20 one. This is done by providing the XCON URI of the parent object =20 inside the element. Is this right? Indeed, the only =20 way to clone a conference object is (see section 5.3 in =20 draft-ietf-xcon-examples-02) by sending a confRequest/create message =20 to the server, with no conference document attached and with the =20 XCON-URI of the object-to-be-cloned in the confObjID parameter. =20 Subsequent updates to such new document can be made through =20 confRequest/update messages. Note that the element is created by the server and =20 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 =20 related to the CCMP. Cloning and associated policies are treated in =20 RFC 5239, section 7.1 (Cloning Tree). Our interpretation of such part =20 of the framework is that the so-called "parent-enforceable" mechanism =20 is something hidden from the clients (i.e. it is a server-specific =20 issue). If this were not the case, then the data model should contain =20 a boolean "parent-enforceable" attribute for all elements that can be =20 subject to such mechanism, which is not the case at this moment. Do Mary, Oscar and the other authors of the mentioned documents (RFC =20 5239 and draft-ietf-xcon-common-data-model) confirm our assumption? Thanks 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 Jan 25 11:06:05 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 20F3A3A683C for ; Mon, 25 Jan 2010 11:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, 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 oZ9+s7ro8Qm2 for ; Mon, 25 Jan 2010 11:06:04 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id DE87E28C0EA for ; Mon, 25 Jan 2010 11:06:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0PJ63S6024250; Mon, 25 Jan 2010 20:06:03 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 25 Jan 2010 20:06:03 +0100 Message-ID: <20100125200603.evazwal88wgc080w@webmail.unina.it> Date: Mon, 25 Jan 2010 20:06:03 +0100 From: spromano@unina.it To: "Richard L. Barnes" References: <4408C6EC74CC3D42824FD68FDA8E8F71010716F2@306900ANEX2.global.avaya.com> <20100125183053.ztrf0b7m74g0wsss@webmail.unina.it> <707BE072-7C57-46EB-AE54-A8843E3D87E4@bbn.com> In-Reply-To: <707BE072-7C57-46EB-AE54-A8843E3D87E4@bbn.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-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: Mon, 25 Jan 2010 19:06:05 -0000 Hi Richard, we're fine with this. Simon Quoting "Richard L. Barnes" : >>> [SEAN] XPATH definietly will work and covers all filter =20 >>> possibilities. However, should the draft state that a server could =20 >>> only support a limited,documented set of xpath queries? >>> Support for a complete range of xpath queries would/could be =20 >>> difficult to implement .... >> >> [spromano] Yes. I think we should definitely take your advice. A =20 >> minimal set of xpath queries should be considered as mandatory for =20 >> any CCMP-compliant server. We were thinking of things like =20 >> "conference state" (active, registered, etc.), conference =20 >> participants, conference media (info about all media involved in a =20 >> conference), and the like. Do you have any other clue on this? > > 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 --=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 Jan 26 02:58: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 76EB03A6823 for ; Tue, 26 Jan 2010 02:58:59 -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 YWTFzdPPhaOd for ; Tue, 26 Jan 2010 02:58:58 -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 2CD3A3A67F5 for ; Tue, 26 Jan 2010 02:58:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,345,1262581200"; d="scan'208";a="173934357" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jan 2010 05:59:05 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jan 2010 05:58:24 -0500 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, 26 Jan 2010 10:58:17 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A48B8@306900ANEX2.global.avaya.com> In-Reply-To: <20100125200603.evazwal88wgc080w@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Thread-Index: Acqd8xwP5hMgOJtJR8mLhlb0wVQFRQAgWUcg References: <4408C6EC74CC3D42824FD68FDA8E8F71010716F2@306900ANEX2.global.avaya.com><20100125183053.ztrf0b7m74g0wsss@webmail.unina.it><707BE072-7C57-46EB-AE54-A8843E3D87E4@bbn.com> <20100125200603.evazwal88wgc080w@webmail.unina.it> From: "Duddy, Sean (Sean)" To: , "Richard L. Barnes" Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-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: Tue, 26 Jan 2010 10:58:59 -0000 Yes there are many xpath libraries out there which work fine if the CCMP = server has its conferences stored in a XML database.=20 However the majority of CCMP implementations I would imagine would be = backed by some sort of RDBMS along with other internal components which = means=20 the implementor must convert all the conference data to xml and then = apply the XPATH filter.... This wont perform on a large conferencing = system All I am suggesting is that the spec allows for the possibility of some = implementations supporting a subset of xpath filters and if a xpath = filter is passed down that is not supported an exception is thrown... -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 25 January 2010 19:06 To: Richard L. Barnes Cc: Duddy, Sean (Sean); xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Hi Richard, we're fine with this. Simon Quoting "Richard L. Barnes" : >>> [SEAN] XPATH definietly will work and covers all filter =20 >>> possibilities. However, should the draft state that a server could =20 >>> only support a limited,documented set of xpath queries? >>> Support for a complete range of xpath queries would/could be =20 >>> difficult to implement .... >> >> [spromano] Yes. I think we should definitely take your advice. A =20 >> minimal set of xpath queries should be considered as mandatory for =20 >> any CCMP-compliant server. We were thinking of things like =20 >> "conference state" (active, registered, etc.), conference =20 >> participants, conference media (info about all media involved in a =20 >> conference), and the like. Do you have any other clue on this? > > It's not clear to me how using a subset of XPath queries creates any=20 > benefit here. There are several XPath libraries out there that cover=20 > the complete spec, so it's not hard for CCMP implementations can get=20 > full XPath by using one of them. And the alternatives seem=20 > 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 --=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 Jan 26 03:09:43 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 530F83A6826 for ; Tue, 26 Jan 2010 03:09:43 -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 2u9qFpbFDban for ; Tue, 26 Jan 2010 03:09:42 -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 CCB1D3A682A for ; Tue, 26 Jan 2010 03:09:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,345,1262581200"; d="scan'208";a="173935576" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jan 2010 06:09:50 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jan 2010 06:09:18 -0500 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, 26 Jan 2010 11:09:17 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A48BC@306900ANEX2.global.avaya.com> In-Reply-To: <20100125192928.99xxw9naf48ocs08@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: Acqd7FhPGOqh+i13SMu8DM5a8RqnyAAisuhA References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A44D1@306900ANEX2.global.avaya.com> <20100125192928.99xxw9naf48ocs08@webmail.unina.it> From: "Duddy, Sean (Sean)" To: 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, 26 Jan 2010 11:09:43 -0000 Hi Simon See below:- -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 25 January 2010 18:29 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05 Hi again, Sean, > Hi All, > Some more comments:- > > 1. What is the expected behaviour of a CCMP server when a client=20 > attempts to create a conference via implicit cloning, and the supplied = > xcon URI (via the entity attribute) already exists on the server side? = > I am thinking we should have another ResponseCode of=20 > 'objectAlreadyExists'. > BTW: In the CCMP examples - "Create Basic Conference from user=20 > provided conference-info", the xml is missing the mandatory entity = attribute. > > I would imagine most CCMP servers would generate the XCON URI, so do=20 > we need to define a default XCON URI to indicate to the server that it = > must generate one? > [spromano] Actually, you are right on this and you are raising here a = general issue, concerning all cases in which the client provides = information to the server in the form of a conference document (or part = of it). We did not take into account the fact that there are some fields = in the data model which are required (e.g. "entity" in "conference-type" = or in "conference-medium-type", "id" in "media-type", etc.). This is due = to the fact that the original data model in RFC4575 has been conceived = for sending information FROM a conference server TO a conference client, = while CCMP has been devised also with the opposite hypothesis in mind = (information flows also along the direction FROM client TO server). = Hence, we should definitely modify our document by introducing a sort of = "wildcard" =20 value for the above fields in all cases where they cannot be populated = by the client since they have not been created yet. As an example, in the mentioned case of the "implicit cloning" of a = conference (as in par. 5.2 of draft-ietf-xcon-examples-02), we should = modify the call flow as follows: ********* CURRENT VERSION ********* xcon-userid:Alice@example.com create [......] ******** END CURRENT VERSION ******* ******* UPDATED VERSION ************ xcon-userid:Alice@example.com create [......] ******** END UPDATED VERSION ******************** The difference between the two versions resides just in the use of a = "CREATE" wildcard value for the mandatory "entity" attribute. The same solution should be applied to all of the above mentioned cases. Do you think this is the right approach? In such case, we'll modify both = the CCMP and the call flows drafts. [SEAN]: Well I think the default/wildcard entity should still conform to = the xcon URI format for consistency of this field,=20 How about xcon:AUTO_GENERATE@example.com?=20 > 2. The 'blueprintInfo' element needs to have a minOccurs=3D"0" to = allow=20 > for responses that may not have a info:conference-type element e.g.=20 > for blueprint delete, or for blueprint operations that have returned=20 > in error. > The same applies for 'confInfo' element. There are probably other=20 > response elements that require this change also... [spromano] Right. We'll check all of them. [SEAN] Thanks 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 Jan 26 03:10: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 A77103A68A7 for ; Tue, 26 Jan 2010 03: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 M6mFoEymm5zy for ; Tue, 26 Jan 2010 03:10:37 -0800 (PST) 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 8B7563A6826 for ; Tue, 26 Jan 2010 03:10:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,346,1262581200"; d="scan'208";a="1664350" 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 Jan 2010 06:10:44 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jan 2010 06:10:04 -0500 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, 26 Jan 2010 11:09:51 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A48BF@306900ANEX2.global.avaya.com> In-Reply-To: <20100125193039.z1q12v0d2ck0c8cg@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-examples-02 Thread-Index: Acqd7qJkJCgBfDd1Qe28MiffFAWu2wAiWgrA References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A4671@306900ANEX2.global.avaya.com> <20100125193039.z1q12v0d2ck0c8cg@webmail.unina.it> From: "Duddy, Sean (Sean)" To: Cc: xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-examples-02 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, 26 Jan 2010 11:10:38 -0000 Thanks Simon.=20 -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 25 January 2010 18:31 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-examples-02 Hi again :-), > Hi, > This docoument should have an example on how the =20 > element gets populated... ...we'll work on it. We'll try and provide a nice example. 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 Tue Jan 26 03:30:54 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 208D13A683B for ; Tue, 26 Jan 2010 03:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.528 X-Spam-Level: * X-Spam-Status: No, score=1.528 tagged_above=-999 required=5 tests=[AWL=-0.353, 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 Rr5lZf9ZG+WX for ; Tue, 26 Jan 2010 03:30:53 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 6D1083A6823 for ; Tue, 26 Jan 2010 03:30:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0QBUwRl030571; Tue, 26 Jan 2010 12:30:58 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Tue, 26 Jan 2010 12:30:58 +0100 Message-ID: <20100126123058.lx0obacz4sookog8@webmail.unina.it> Date: Tue, 26 Jan 2010 12:30:58 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A44D1@306900ANEX2.global.avaya.com> <20100125192928.99xxw9naf48ocs08@webmail.unina.it> <4408C6EC74CC3D42824FD68FDA8E8F71010A48BC@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A48BC@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] 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, 26 Jan 2010 11:30:54 -0000 Hi Sean, > [SEAN]: Well I think the default/wildcard entity should still =20 > conform to the xcon URI format for consistency of this field, > How about xcon:AUTO_GENERATE@example.com? +1 from me! I like this proposal. 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 Jan 26 03:38:05 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 1029F3A67E5 for ; Tue, 26 Jan 2010 03:38:05 -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 eNuH6buK-LNn for ; Tue, 26 Jan 2010 03:38:04 -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 D508D3A677D for ; Tue, 26 Jan 2010 03:38:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,346,1262581200"; d="scan'208";a="202220138" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Jan 2010 06:38:13 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jan 2010 06:38:12 -0500 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, 26 Jan 2010 11:37:54 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A48D5@306900ANEX2.global.avaya.com> In-Reply-To: <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: Acqd8aOgyqNdNxDwSimRxpHTkDsEIAAh6E4A References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com> <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> From: "Duddy, Sean (Sean)" To: 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, 26 Jan 2010 11:38:05 -0000 Hi Simon, See below. -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 25 January 2010 19:04 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05 Hi Sean, > Hi All, > I would like some clarification on the use of the =20 > element with the CCMP protocol. > My understanding is that this element is not returned in confResponse=20 > where a conference is cloned from a blueprint. Is that correct? [spromano] Yes, it is. [SEAN] OK Section 7.3 of the CCMP spec needs to change to reflect this. = BTW do we need examples in the CCMP doc as well as the new examples doc? Personally I think we should have only one reference for examples and = maybe as an appendix to the CCMP? > > What if I want to clone an existing conference? Would the=20 > element be returned in the confResponse? [spromano] Yes. > > If a conference has a element, does that imply that=20 > 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 = 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. =20 Subsequent updates to such new document can be made through = confRequest/update messages. Note that the element is created by the server and sent = back to the client. [SEAN] that's all fine by me. However I think it would be a nice feature = to allow a conference doc to be passed down in a cloning operation. = Right now if I want to use a blueprint but obviously want a person name = for my conference, I must first send down the create and then follow this up with the update. I = don't see any down side to allowing a conf doc to be supplied in the = create also, so the CCMP server would first clone the existing = conference, then apply the changes from the conf doc provided all in one = transaction... > And if a parent obect > is modified, these changes would be applied to its children also by=20 > the server? > I recall a while back that it may be possible to specify what=20 > attributes can be overridden by a child conference. How is that = achieved? > > Finally, I assume CCMP would support the possibility to break this=20 > parent/child relationship, by sending an confRequest update with an=20 > empty element? > > I think the ccmp draft needs to add in some more detail and possibly=20 > 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 = 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. [SEAN] OK it is not CCMP related and it is data model related, but it = all needs to tie in to a complete solution. The CCMP/Data model needs to = provide clarity on this issue. Well yes I think a "parent-enforceable" attribute would be a very useful = feature. This would allow admin to modify a blueprint (e.g. max user = count) which could get pushed down the conferences that got created from = it etc Do Mary, Oscar and the other authors of the mentioned documents (RFC 5239 and draft-ietf-xcon-common-data-model) confirm our assumption? Thanks 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 duddy@avaya.com Tue Jan 26 04:22:11 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 819F33A690B for ; Tue, 26 Jan 2010 04:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 7cn4Qq82V15E for ; Tue, 26 Jan 2010 04:22:10 -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 B2ADF3A6826 for ; Tue, 26 Jan 2010 04:22:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,346,1262581200"; d="scan'208";a="1666751" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 26 Jan 2010 07:22:19 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jan 2010 07:22:18 -0500 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, 26 Jan 2010 12:21:57 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010A48F5@306900ANEX2.global.avaya.com> In-Reply-To: <20091221184113.30kq2duam8w8gcow@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Thread-Index: AcqCZM8SuU9lU4KtTDGTJwZFoyohSgcGO5lw References: <20091112020002.1703D3A68FC@core3.amsl.com><4408C6EC74CC3D42824FD68FDA8E8F7101016451@306900ANEX2.global.avaya.com> <20091221184113.30kq2duam8w8gcow@webmail.unina.it> From: "Duddy, Sean (Sean)" To: Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-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: Tue, 26 Jan 2010 12:22:11 -0000 Hi Simon, I am still confused about the purpose of the confUserId/password = fields. I would have thought that all CCMP requests would require these fields for authentication purposes? I think CCMP has too many purposes = for these fields and we need to refine the ccmp xml data model. Even a simple example, say I want to retrieve all my conferences, what = password do I supply? And then if I want to modify an individual = conference=20 I must supply the conference passcode. Which implies any particpant of = the conference could work out the 'AA' details to modify the = conference.. I propose the following change:- minOccurs=3D"1" maxOccurs=3D"1" /> minOccurs=3D"0" maxOccurs=3D"1" /> The subject details are independent of the conference details. Sean -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 21 December 2009 17:41 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt Hi Sean, thank you for your comments. Please find my answers in-line (with a = prefix of [spromano]). BTW, we are going to submit a fresh version of = the CCMP draft in the next few days. > General: > The new element needs to be expanded to=20 > indicate its type. > E.g. a conference could have a moderator and conferee password and=20 > the ccmp client would > need to know which is which. [spromano] I take this as a suggestion to modify the data model, rather = than the CCMP, since in the draft we are just referring to [I D.ietf = xcon common data model]. This said, I personally think that you are touching again the important = issue of defining a role-based access control policy system associated = with the management of conferences, users and their respective roles. I = keep on thinking that such system is somehow "orthogonal" to the = framework itself. Let me once again self-reference an old post about this topic: http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html When we are eventually done with the last issues related to CCMP, I will = be glad to work on the above proposal, if there is some interest in = carrying it out. > 6.1 CCMP Request Message Type > confUserID/password > The purpose of these elements is not clear. The draft states that the = > password should contain > the value of the xcon:conference-password element. [spromano] ?confUserId? is used to know who is asking to perform a = certain operation (e.g. for AAA purposes). When such information is = missing in a "userRequest/create" operation, this means that the request = itself is a join operation PLUS creation of an xcon-userid (and related = association tree on the server's side: sip-uri, xcon-uri, role, etc.) = associated with the sender. This should become clearer in the general sample call flows contained in = the draft, as well as in the detailed flows presented in the companion = XCON call flows draft. As to the password, see the answer to your previous comment. > > Section 6.3.6 states that the XCON-USERID could be an administrator=20 > or some other non conference participating user > of the ccmp server. In this case, the password field in the request=20 > would be that of the administrator and would have nothing to > do with the conferences he/she is about to provision. > > So to summarise: The request password field may be a conference=20 > password but it also may be some other piece of info to authenticate > the client issuing the command. [spromano] The "password" field is optional. Again, we look at it as = being strictly related to the conference, as per the = element of the data model. We have not taken into = account the case of a non-participating administrator who is willing to = use such field to enter the conferencing system and carry out CCMP-based = operations. Stated in different terms, we did not face the issue of = authenticating the system administrator via a field other than his own = xcon-userid. I would ask other people in the WG to express their opinion on this = topic. > > 6.3.2. confsRequest and confsResponse > A filter mechanism needs to be specified here to allow clients only=20 > retreieve a subset of conferences based on search crieteria. > e.g. A ccmp client might only be interested in conferences pertaining = > to a certain user or active conferences between a date range etc. [spromano] Right! We already proposed to add filters to both = confsRequest and blueprintsRequest messages. Our idea would be the = following (you'll find it in the upcoming versions of the draft), with = reference, e.g. to the former message: As you can see, we propose to add an optional "xpathFilter" element (of = a generic "xs:string" type) to the message, in order to allow the server = to appropriately filter out unwanted information before sending back to = the client the list of conferences. Example --> retrieve just registered conferences: xpathFilter=3D"/info:conference-info[info:conference-state/info:active=3D= 'false']"; What is your feeling about such proposal? Do you think it does the job? = Or should we go for a finer-grained definition of the new element (which = might be bound, for example, to sharply represent an xpath query rather = than a generic string)? > > 6.3.2 Related to the 6.1 issues, if an administrator wants to = retrieve > a user belonging to a conference, where in the userRequest message > is the user XCON ID specified? It looks like it is specified=20 > in confUserID which would be wrong in this case.... [spromano] The xcon-userid of the target user is contained inside the = "entity" attribute of the userRequest/retrieve message. Example: Alice is administrator and wants to retrieve Bob's info, with = Bob being a participant in conference 8977777. Alice sends the following = message via the CCMP: = xcon-userid:alice@example.com xcon:8977777@example.com retrieve Inside the response, ?confUserId? contains = ?xcon-userid:alice@example.com?, whereas the ?userInfo? parameter = carries back Bob's information. > > 6.3.4. confRequest and confResponse > This is a general question. If one develops a CCMP based provisioning = > client to simply provision conferences on the server, > they are not interested in the conference runtime parameters of=20 > conferences like the entities. Not a big deal for the client, > they can simply ignore this info, but it is a significent performance = > hit for the CCMP server to provide up to date conference runtime > info to clients... I think we need some mechanism to avoid this=20 > overhead for clients that do not need this info. [spromano] If one wants to retrieve general information about available = conferences, he can issue a confsRequest message, whose response will = contain high-level information (in particular, all that can be inserted = in a "uri-type" element -- display-text, uri, purpose, etc. --). A = drill-down query can be issued by sending a confRequest message = associated with a specific conference object. In principle, the entire = conference document is sent back to the client, even though the choice = of what kind of information to provide (e.g. users list, passwords, = etc.) is completely implementation-dependent. The only requirement is = for the server to send back an xml element compliant with the = "conference-type" element of the data model. Once again, a policy-based = approach might be put into place to properly identify/discriminate "who = is trying to do what" and (re)act accordingly. Finally, if a user wants to retrieve fragments of a conference object = (e.g. info about a certain user, all users, sidebars, etc), she can = exploit the ad-hoc conceived messages made available by the protocol. =20 As you will have noticed, when deciding what messages to define for the = CCMP, we tried to strike the balance between granularity of the protocol = and its complexity. > > 10 HTTP Transport > Link 'Section 7.2.1.' does not exist > > Sean [spromano] Right. Thank you for pointing this out. Cheers, Simon > > > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf=20 > Of Internet-Drafts@ietf.org > Sent: 12 November 2009 02:00 > To: i-d-announce@ietf.org > Cc: xcon@ietf.org > Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Centralized Conferencing Working=20 > Group of the IETF. > > > Title : Centralized Conferencing Manipulation Protocol > Author(s) : M. Barnes, et al. > Filename : draft-ietf-xcon-ccmp-04.txt > Pages : 98 > Date : 2009-11-11 > > The Centralized Conferencing Manipulation Protocol (CCMP) can create,=20 > retrieve, change and delete objects describing a centralized=20 > conference, such as state and capabilities of the conference,=20 > participants, and their roles. The conference information is=20 > contained in XML documents and fragments conforming to the centralized = > conferencing data model schema. Even though the goal of the CCMP is=20 > to appropriately manage conference state, the mechanisms upon which=20 > the protocol itself is built are based on a state-less=20 > request/response paradigm. Conferencing clients send requests to=20 > conference servers, which respond to the client with the conference = information. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the=20 > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering Task = > Force (IETF), its areas, and its working groups. Note that other=20 > groups may also distribute working documents as Internet- Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months=20 > and may be updated, replaced, or obsoleted by other documents at any=20 > time. It is inappropriate to use Internet-Drafts as reference=20 > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at=20 > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at=20 > http://www.ietf.org/shadow.html. > This Internet-Draft will expire on May 16, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the=20 > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal=20 > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of=20 > publication of this document. Please review these documents=20 > carefully, as they describe your rights and restrictions with respect=20 > to this document. Code Components extracted from this document must=20 > include Simplified BSD License text as described in Section 4.e of the = > Trust Legal Provisions and are provided without warranty as described=20 > in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > _______________________________________________ > 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 duddy@avaya.com Wed Jan 27 04:14:01 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 A36FA3A6A73 for ; Wed, 27 Jan 2010 04:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 otZRTot5fXHF for ; Wed, 27 Jan 2010 04:14:00 -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 380DD3A6A4B for ; Wed, 27 Jan 2010 04:13:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,353,1262581200"; d="scan'208,217";a="174135750" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jan 2010 07:14:03 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2010 07:14:02 -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_01CA9F4A.29DD2740" Date: Wed, 27 Jan 2010 12:13:39 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D14E6@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-common-data-model-14 Thread-Index: AcqfSij3aQa6iQTxQq+jLBhs8rRvvg== 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, 27 Jan 2010 12:14:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9F4A.29DD2740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The new password field in draft-ietf-xcon-common-data-model-14 is defined as follows:- =20 =20 In section 4.2.10, it states that this field contain password(s). What would 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. =20 Does the purpose field defined in rfc4575 need to be extended to indicate the type of URI i.e. moderator,particpant etc? Or how would a client that just created a conference distinguish between the URIs? =20 Regards Sean ------_=_NextPart_001_01CA9F4A.29DD2740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
   =20 The new password field in =  draft-ietf-xcon-common-data-model-14 is=20 defined as follows:-
 
    <xs:element=20 name=3D"conference-password" type=3D"xs:string"/>
 
In = section 4.2.10,=20 it states that this field contain password(s). What would be the usecase = for=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 = would a=20 client that just created a conference distinguish between the=20 URIs?
 
Regards
Sean
------_=_NextPart_001_01CA9F4A.29DD2740-- From spromano@unina.it Wed Jan 27 10:51:22 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 4274A3A6927 for ; Wed, 27 Jan 2010 10:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.587 X-Spam-Level: * X-Spam-Status: No, score=1.587 tagged_above=-999 required=5 tests=[AWL=-0.294, 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 SS9OUBpp3uvq for ; Wed, 27 Jan 2010 10:51:21 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 0EC443A6861 for ; Wed, 27 Jan 2010 10:51:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0RIpWiq026579; Wed, 27 Jan 2010 19:51:32 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Wed, 27 Jan 2010 19:51:32 +0100 Message-ID: <20100127195132.wbfoexc3tww8cw4c@webmail.unina.it> Date: Wed, 27 Jan 2010 19:51:32 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com> <20100125200348.w00lwy5y8gwwgoww@webmail.unina.it> <4408C6EC74CC3D42824FD68FDA8E8F71010A48D5@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A48D5@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] 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, 27 Jan 2010 18:51:22 -0000 Hi Sean, here we go again ;-). First of all, as regards blueprints, conferences =20 and the parent/child relationship, our proposal would be to consider =20 blueprints and conferences as two related yet independent concepts. If you allow me to draw a comparison, I would say that a blueprint is =20 like a C++ "template", whereas a conference is like a C++ "class". =20 Under this perspective, the parent/child relationship just holds =20 between conferences (i.e. conference B may be a child of conference A, =20 but no conference is a child of a blueprint, even though it might have =20 been created through a blueprint cloning operation). I think we =20 discussed this some IETFs ago, at the f2f meeting; though, we can =20 decide that we don't want to keep on having this distinction. This said, your idea of having modifications to a parent conference =20 propagate (through the parent-enforceable attribute -- which btw =20 should be explicitely introduced in the data model) to the children it =20 has generated looks interesting to us. Here again I would ask for =20 other people's opinions on the list. Once we have an agreed-upon =20 decision, we go and modify the draft in order to reflect it. > [SEAN] that's all fine by me. However I think it would be a nice =20 > feature to allow a conference doc to be passed down in a cloning =20 > operation. Right now if I want to use a blueprint but obviously want =20 > a person name for my conference, I must > first send down the create and then follow this up with the update. =20 > I don't see any down side to allowing a conf doc to be supplied in =20 > the create also, so the CCMP server would first clone the existing =20 > conference, then apply the changes from the conf doc provided all in =20 > one transaction... [spromano] This was also discussed before. I think we decided to stick =20 to the simpler mechanism whereby you issue "atomic" requests to the =20 server. This avoids any potential complication due to server-specific =20 implementations of the cloning mechanism. > [SEAN] OK it is not CCMP related and it is data model related, but =20 > it all needs to tie in to a complete solution. The CCMP/Data model =20 > needs to provide clarity on this issue. > Well yes I think a "parent-enforceable" attribute would be a very =20 > useful feature. This would allow admin to modify a blueprint (e.g. =20 > max user count) which could get pushed down the conferences that got =20 > created from it etc [spromano] Apart from my initial comment associated with blueprints =20 (i.e. everything looks ok to us if you replace the blueprint with a =20 parent conference..), conferences and cloning operations, I do agree =20 that this would be a nice feature to add. 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 Wed Jan 27 10:54:50 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 64B2C3A689F for ; Wed, 27 Jan 2010 10:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.629 X-Spam-Level: * X-Spam-Status: No, score=1.629 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 Tpeg2MjL-6av for ; Wed, 27 Jan 2010 10:54:49 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 49FD33A67CC for ; Wed, 27 Jan 2010 10:54:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0RIt2EQ027092; Wed, 27 Jan 2010 19:55:02 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Wed, 27 Jan 2010 19:55:02 +0100 Message-ID: <20100127195502.v754hyjt440wg0sk@webmail.unina.it> Date: Wed, 27 Jan 2010 19:55:02 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <20091112020002.1703D3A68FC@core3.amsl.com><4408C6EC74CC3D42824FD68FDA8E8F7101016451@306900ANEX2.global.avaya.com> <20091221184113.30kq2duam8w8gcow@webmail.unina.it> <4408C6EC74CC3D42824FD68FDA8E8F71010A48F5@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010A48F5@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-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, 27 Jan 2010 18:54:50 -0000 Sean, > I propose the following change:- > > name=3D"ccmp-request-message-type"> > > is a JAAS term it could be renamed to something else...--> > minOccurs=3D"1" maxOccurs=3D"1" /> > minOccurs=3D"0" maxOccurs=3D"1" /> > minOccurs=3D"0" maxOccurs=3D"1" /> > minOccurs=3D"0" maxOccurs=3D"1" /> > rename password to conference-password--> > minOccurs=3D"0" maxOccurs=3D"1" /> > > > > > > > minOccurs=3D"0" maxOccurs=3D"1" /> > minOccurs=3D"0" maxOccurs=3D"1" /> > =09 minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > The subject details are independent of the conference details. [spromano] I like this suggestion. This would completely decouple AAA =20 issues from conference-related issues. Shall we proceed? Personally, I =20 also like the JAAS-style "subject" term. 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 Wed Jan 27 11:07:12 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 605713A689F for ; Wed, 27 Jan 2010 11:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.661 X-Spam-Level: * X-Spam-Status: No, score=1.661 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 5BvJZPue+FyN for ; Wed, 27 Jan 2010 11:07:11 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 549463A67F4 for ; Wed, 27 Jan 2010 11:07:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0RJ7MpA028970; Wed, 27 Jan 2010 20:07:22 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Wed, 27 Jan 2010 20:07:22 +0100 Message-ID: <20100127200722.tf0t7zk4g0o8ss4k@webmail.unina.it> Date: Wed, 27 Jan 2010 20:07:22 +0100 From: spromano@unina.it To: Oscar Novo References: <9520E66537CC4941994C518E3E21091CC4BB3F@esealmw105.eemea.ericsson.se> In-Reply-To: <9520E66537CC4941994C518E3E21091CC4BB3F@esealmw105.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it X-Virus-Status: Clean 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, 27 Jan 2010 19:07:12 -0000 Hi Oscar, it looks like the definition of the mentioned elements contains a =20 mismatched "unsignedLong" type. Shouldn't this be of type "anyUri", as =20 per the "entity" 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 meeting, > the authors of the data model are proposing to add the following > elements to the data model to explicit express cloning in the document. > The elements we're planning to add are: > > - cloning-parent: When this element is present, it indicates that the > conference object is a child of a parent conference. This element > contains the conference object Identifier (XCON-URI) (different from the > main XCON-URI) of the parent. > - sidebar-parent; When this element is present, it indicates that the > conference object represents a sidebar of another conference. This > element contains the conference object Identifier (XCON-URI) (different > from the main XCON-URI) of the parent. > > If nobody oppose to this modifications, we'll submit a new version of > the document in brief. > > Of course, any feedback to the document or to the previous 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 duddy@avaya.com Wed Jan 27 13:35:23 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 401183A6931 for ; Wed, 27 Jan 2010 13:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 BjOQls0PUlAR for ; Wed, 27 Jan 2010 13:35:22 -0800 (PST) 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 18AF63A68C3 for ; Wed, 27 Jan 2010 13:35:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,356,1262581200"; d="scan'208";a="1747657" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 27 Jan 2010 16:35:36 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2010 16:35:35 -0500 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: Wed, 27 Jan 2010 21:35:12 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D15DA@306900ANEX2.global.avaya.com> In-Reply-To: <20100127195132.wbfoexc3tww8cw4c@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: AcqfgcZEEKGUosbvQ+i/Kw0OPnPJHgAEyisA References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com><20100125200348.w00lwy5y8gwwgoww@webmail.unina.it><4408C6EC74CC3D42824FD68FDA8E8F71010A48D5@306900ANEX2.global.avaya.com> <20100127195132.wbfoexc3tww8cw4c@webmail.unina.it> From: "Duddy, Sean (Sean)" To: 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: Wed, 27 Jan 2010 21:35:23 -0000 Hi Simon, See below...=20 -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 27 January 2010 18:52 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: RE: [XCON] Comments on draft-ietf-xcon-ccmp-05 Hi Sean, here we go again ;-). First of all, as regards blueprints, conferences = and the parent/child relationship, our proposal would be to consider = blueprints and conferences as two related yet independent concepts. If you allow me to draw a comparison, I would say that a blueprint is = like a C++ "template", whereas a conference is like a C++ "class". =20 Under this perspective, the parent/child relationship just holds between = conferences (i.e. conference B may be a child of conference A, but no = conference is a child of a blueprint, even though it might have been = created through a blueprint cloning operation). I think we discussed = this some IETFs ago, at the f2f meeting; though, we can decide that we = don't want to keep on having this distinction. [SEAN] Well I think the CCMP protocol should be as flexible as possible = and should treat the behaviour of blueprints and conferences the same = when they are parents. I also think the CCMP protocol should allow the = possibility of breaking the parent/child relationship by allowing = updates with null elements. I think a typical use case = is where somebody has a known working conference and just wants an = independent clone of it. I don't really see the usecase for parent/child = conferences but it is no harm having that possibility though... This said, your idea of having modifications to a parent conference = propagate (through the parent-enforceable attribute -- which btw should = be explicitely introduced in the data model) to the children it has = generated looks interesting to us. Here again I would ask for other = people's opinions on the list. Once we have an agreed-upon decision, we = go and modify the draft in order to reflect it. > [SEAN] that's all fine by me. However I think it would be a nice =20 > feature to allow a conference doc to be passed down in a cloning =20 > operation. Right now if I want to use a blueprint but obviously want =20 > a person name for my conference, I must > first send down the create and then follow this up with the update. =20 > I don't see any down side to allowing a conf doc to be supplied in =20 > the create also, so the CCMP server would first clone the existing =20 > conference, then apply the changes from the conf doc provided all in =20 > one transaction... [spromano] This was also discussed before. I think we decided to stick = to the simpler mechanism whereby you issue "atomic" requests to the = server. This avoids any potential complication due to server-specific = implementations of the cloning mechanism. [SEAN] Well it is still an atomic operation, actually with the current = mechanism, a CCMP client will at least need to make two CCMP requests to = create a conference... I don't see wny the CCMP draft should restrict = supplying a conf doc in the update, It really simplfies CCMP client = behaviour... > [SEAN] OK it is not CCMP related and it is data model related, but =20 > it all needs to tie in to a complete solution. The CCMP/Data model =20 > needs to provide clarity on this issue. > Well yes I think a "parent-enforceable" attribute would be a very =20 > useful feature. This would allow admin to modify a blueprint (e.g. =20 > max user count) which could get pushed down the conferences that got =20 > created from it etc [spromano] Apart from my initial comment associated with blueprints = (i.e. everything looks ok to us if you replace the blueprint with a = parent conference..), conferences and cloning operations, I do agree = that this would be a nice feature to add. 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 Thu Jan 28 03:04:32 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 4D3E13A67B4 for ; Thu, 28 Jan 2010 03:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.385 X-Spam-Level: X-Spam-Status: No, score=0.385 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599, 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 P2PAn7dmab14 for ; Thu, 28 Jan 2010 03:04:31 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 07B923A68EB for ; Thu, 28 Jan 2010 03:04:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o0SB4ffO026934; Thu, 28 Jan 2010 12:04:41 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 28 Jan 2010 12:04:41 +0100 Message-ID: <20100128120441.luh7z9kfms08gcs8@webmail.unina.it> Date: Thu, 28 Jan 2010 12:04:41 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com><20100125200348.w00lwy5y8gwwgoww@webmail.unina.it><4408C6EC74CC3D42824FD68FDA8E8F71010A48D5@306900ANEX2.global.avaya.com> <20100127195132.wbfoexc3tww8cw4c@webmail.unina.it> <4408C6EC74CC3D42824FD68FDA8E8F71010D15DA@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71010D15DA@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] 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, 28 Jan 2010 11:04:32 -0000 Hi Sean, I think we are stuck on the points below, meaning that both your =20 modification proposals are applicable, even though I personally keep =20 on preferring the way they are currently done. Once again, I encourage =20 people on the ML to raise their voice ;-). More precisely: 1: as to the distinction between blueprints and actual conference =20 objects, I would be in favour of keeping it; 2: as to the "atomicity" of CCMP creation requests, I would be in =20 favour of keeping creation via cloning separate from a subsequent =20 modification via update. With respect to this last point, in =20 particular, even though the "create+update" operation might look =20 atomic from the client perspective, it definitely is not such from the =20 server's viewpoint. Our experience with implementing the CCMP taught us that there are a =20 bunch of tricky issues you have to face when playing with all of the =20 subtle interrelations among the fields of the data model, especially =20 wnen creating chieldren and sidebars. BTW, are you guys in Avaya =20 currently implementing the protocol? In such case, it would be nice to =20 share our experiences and start asap some interoperability tests. Cheers, Simon Quoting "Duddy, Sean (Sean)" : > Hi Simon, > =09See below... > > -----Original Message----- > From: spromano@unina.it [mailto:spromano@unina.it] > Sent: 27 January 2010 18:52 > To: Duddy, Sean (Sean) > Cc: xcon@ietf.org > Subject: RE: [XCON] Comments on draft-ietf-xcon-ccmp-05 > > Hi Sean, > > here we go again ;-). First of all, as regards blueprints, =20 > conferences and the parent/child relationship, our proposal would be =20 > to consider blueprints and conferences as two related yet =20 > independent concepts. > If you allow me to draw a comparison, I would say that a blueprint =20 > is like a C++ "template", whereas a conference is like a C++ "class". > Under this perspective, the parent/child relationship just holds =20 > between conferences (i.e. conference B may be a child of conference =20 > A, but no conference is a child of a blueprint, even though it might =20 > have been created through a blueprint cloning operation). I think =20 > we discussed this some IETFs ago, at the f2f meeting; though, we =20 > can decide that we don't want to keep on having this distinction. > > [SEAN] Well I think the CCMP protocol should be as flexible as =20 > possible and should treat the behaviour of blueprints and =20 > conferences the same when they are parents. I also think the CCMP =20 > protocol should allow the possibility of breaking the parent/child =20 > relationship by allowing updates with null =20 > elements. I think a typical use case is where somebody has a known =20 > working conference and just wants an independent clone of it. I =20 > don't really see the usecase for parent/child conferences but it is =20 > no harm having that possibility though... > > > This said, your idea of having modifications to a parent conference =20 > propagate (through the parent-enforceable attribute -- which btw =20 > should be explicitely introduced in the data model) to the children =20 > it has generated looks interesting to us. Here again I would ask for =20 > other people's opinions on the list. Once we have an agreed-upon =20 > decision, we go and modify the draft in order to reflect it. > >> [SEAN] that's all fine by me. However I think it would be a nice >> feature to allow a conference doc to be passed down in a cloning >> operation. Right now if I want to use a blueprint but obviously want >> a person name for my conference, I must >> first send down the create and then follow this up with the update. >> I don't see any down side to allowing a conf doc to be supplied in >> the create also, so the CCMP server would first clone the existing >> conference, then apply the changes from the conf doc provided all in >> one transaction... > > [spromano] This was also discussed before. I think we decided to =20 > stick to the simpler mechanism whereby you issue "atomic" requests =20 > to the server. This avoids any potential complication due to =20 > server-specific implementations of the cloning mechanism. > [SEAN] Well it is still an atomic operation, actually with the =20 > current mechanism, a CCMP client will at least need to make two CCMP =20 > requests to create a conference... I don't see wny the CCMP draft =20 > should restrict supplying a conf doc in the update, It really =20 > simplfies CCMP client behaviour... > >> [SEAN] OK it is not CCMP related and it is data model related, but >> it all needs to tie in to a complete solution. The CCMP/Data model >> needs to provide clarity on this issue. >> Well yes I think a "parent-enforceable" attribute would be a very >> useful feature. This would allow admin to modify a blueprint (e.g. >> max user count) which could get pushed down the conferences that got >> created from it etc > > [spromano] Apart from my initial comment associated with blueprints =20 > (i.e. everything looks ok to us if you replace the blueprint with a =20 > parent conference..), conferences and cloning operations, I do agree =20 > that this would be a nice feature to add. > > 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~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > --=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 Thu Jan 28 03:21:00 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 256703A6845 for ; Thu, 28 Jan 2010 03:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rG5NtsawNtYF for ; Thu, 28 Jan 2010 03:20:58 -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 E8C123A6A30 for ; Thu, 28 Jan 2010 03:20:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,359,1262581200"; d="scan'208";a="202698817" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Jan 2010 06:21:14 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Jan 2010 06:20:58 -0500 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: Thu, 28 Jan 2010 11:20:35 -0000 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71010D163D@306900ANEX2.global.avaya.com> In-Reply-To: <20100128120441.luh7z9kfms08gcs8@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-ccmp-05 Thread-Index: AcqgCbrSD0blMdvuRkS8IJjuQjZNGQAAJwUQ References: <4B523F84.4000407@gmail.com><4408C6EC74CC3D42824FD68FDA8E8F71010A4505@306900ANEX2.global.avaya.com><20100125200348.w00lwy5y8gwwgoww@webmail.unina.it><4408C6EC74CC3D42824FD68FDA8E8F71010A48D5@306900ANEX2.global.avaya.com><20100127195132.wbfoexc3tww8cw4c@webmail.unina.it><4408C6EC74CC3D42824FD68FDA8E8F71010D15DA@306900ANEX2.global.avaya.com> <20100128120441.luh7z9kfms08gcs8@webmail.unina.it> From: "Duddy, Sean (Sean)" To: 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: Thu, 28 Jan 2010 11:21:00 -0000 Hi Simon, Yes we are considering using this protcol.... Well the "create+update" is atomic as far as the client is concerned = which is all that matters regarding the protocol, right? Regarding the server implmentations, I think even a simple create in a = server implementation could map to a set of operations to be applied to = the server's existing data model depending on how closely the server's = existing datamodel maps back to the xcon data model... Sean -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: 28 January 2010 11:05 To: Duddy, Sean (Sean) Cc: xcon@ietf.org Subject: RE: [XCON] Comments on draft-ietf-xcon-ccmp-05 Hi Sean, I think we are stuck on the points below, meaning that both your = modification proposals are applicable, even though I personally keep on = preferring the way they are currently done. Once again, I encourage = people on the ML to raise their voice ;-). More precisely: 1: as to the distinction between blueprints and actual conference = objects, I would be in favour of keeping it; 2: as to the "atomicity" of CCMP creation requests, I would be in favour = of keeping creation via cloning separate from a subsequent modification = via update. With respect to this last point, in particular, even though = the "create+update" operation might look atomic from the client = perspective, it definitely is not such from the server's viewpoint. Our experience with implementing the CCMP taught us that there are a = bunch of tricky issues you have to face when playing with all of the = subtle interrelations among the fields of the data model, especially = wnen creating chieldren and sidebars. BTW, are you guys in Avaya = currently implementing the protocol? In such case, it would be nice to = share our experiences and start asap some interoperability tests. Cheers, Simon Quoting "Duddy, Sean (Sean)" : > Hi Simon, > See below... > > -----Original Message----- > From: spromano@unina.it [mailto:spromano@unina.it] > Sent: 27 January 2010 18:52 > To: Duddy, Sean (Sean) > Cc: xcon@ietf.org > Subject: RE: [XCON] Comments on draft-ietf-xcon-ccmp-05 > > Hi Sean, > > here we go again ;-). First of all, as regards blueprints, =20 > conferences and the parent/child relationship, our proposal would be =20 > to consider blueprints and conferences as two related yet =20 > independent concepts. > If you allow me to draw a comparison, I would say that a blueprint =20 > is like a C++ "template", whereas a conference is like a C++ "class". > Under this perspective, the parent/child relationship just holds =20 > between conferences (i.e. conference B may be a child of conference =20 > A, but no conference is a child of a blueprint, even though it might =20 > have been created through a blueprint cloning operation). I think we =20 > discussed this some IETFs ago, at the f2f meeting; though, we can =20 > decide that we don't want to keep on having this distinction. > > [SEAN] Well I think the CCMP protocol should be as flexible as =20 > possible and should treat the behaviour of blueprints and =20 > conferences the same when they are parents. I also think the CCMP =20 > protocol should allow the possibility of breaking the parent/child =20 > relationship by allowing updates with null =20 > elements. I think a typical use case is where somebody has a known =20 > working conference and just wants an independent clone of it. I =20 > don't really see the usecase for parent/child conferences but it is =20 > no harm having that possibility though... > > > This said, your idea of having modifications to a parent conference =20 > propagate (through the parent-enforceable attribute -- which btw =20 > should be explicitely introduced in the data model) to the children =20 > it has generated looks interesting to us. Here again I would ask for =20 > other people's opinions on the list. Once we have an agreed-upon =20 > decision, we go and modify the draft in order to reflect it. > >> [SEAN] that's all fine by me. However I think it would be a nice=20 >> feature to allow a conference doc to be passed down in a cloning=20 >> operation. Right now if I want to use a blueprint but obviously want=20 >> a person name for my conference, I must first send down the create=20 >> and then follow this up with the update. >> I don't see any down side to allowing a conf doc to be supplied in=20 >> the create also, so the CCMP server would first clone the existing=20 >> conference, then apply the changes from the conf doc provided all in=20 >> one transaction... > > [spromano] This was also discussed before. I think we decided to =20 > stick to the simpler mechanism whereby you issue "atomic" requests =20 > to the server. This avoids any potential complication due to =20 > server-specific implementations of the cloning mechanism. > [SEAN] Well it is still an atomic operation, actually with the =20 > current mechanism, a CCMP client will at least need to make two CCMP =20 > requests to create a conference... I don't see wny the CCMP draft =20 > should restrict supplying a conf doc in the update, It really =20 > simplfies CCMP client behaviour... > >> [SEAN] OK it is not CCMP related and it is data model related, but it = >> all needs to tie in to a complete solution. The CCMP/Data model needs = >> to provide clarity on this issue. >> Well yes I think a "parent-enforceable" attribute would be a very=20 >> useful feature. This would allow admin to modify a blueprint (e.g. >> max user count) which could get pushed down the conferences that got=20 >> created from it etc > > [spromano] Apart from my initial comment associated with blueprints =20 > (i.e. everything looks ok to us if you replace the blueprint with a =20 > parent conference..), conferences and cloning operations, I do agree =20 > that this would be a nice feature to add. > > 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~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > --=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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/