From spromano@unina.it Mon Dec 21 09:41:36 2009 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 1C1193A6A6F for ; Mon, 21 Dec 2009 09:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tplNfG1jcHGJ for ; Mon, 21 Dec 2009 09:41:34 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 2BE003A695D for ; Mon, 21 Dec 2009 09:41:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nBLHfDCD027612; Mon, 21 Dec 2009 18:41:14 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 21 Dec 2009 18:41:13 +0100 Message-ID: <20091221184113.30kq2duam8w8gcow@webmail.unina.it> Date: Mon, 21 Dec 2009 18:41:13 +0100 From: spromano@unina.it To: "Duddy, Sean (Sean)" References: <20091112020002.1703D3A68FC@core3.amsl.com> <4408C6EC74CC3D42824FD68FDA8E8F7101016451@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F7101016451@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, 21 Dec 2009 17:41:36 -0000 Hi Sean, thank you for your comments. Please find my answers in-line (with a =20 prefix of [spromano]). BTW, we are going to submit a fresh version of =20 the CCMP draft in the next few days. > General: > =09The new element needs to be expanded > to indicate its type. > =09E.g. a conference could have a moderator and conferee password > and the ccmp client would > =09need to know which is which. [spromano] I take this as a suggestion to modify the data model, =20 rather than the CCMP, since in the draft we are just referring to [I =20 D.ietf xcon common data model]. This said, I personally think that you are touching again the =20 important issue of defining a role-based access control policy system =20 associated with the management of conferences, users and their =20 respective roles. I keep on thinking that such system is somehow =20 "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 =20 will be glad to work on the above proposal, if there is some interest =20 in carrying it out. > 6.1 CCMP Request Message Type > =09confUserID/password > =09The purpose of these elements is not clear. The draft states > that the password should contain > =09the value of the xcon:conference-password element. [spromano] ?confUserId? is used to know who is asking to perform a =20 certain operation (e.g. for AAA purposes). When such information is =20 missing in a "userRequest/create" operation, this means that the =20 request itself is a join operation PLUS creation of an xcon-userid =20 (and related association tree on the server's side: sip-uri, xcon-uri, =20 role, etc.) associated with the sender. This should become clearer in the general sample call flows contained =20 in the draft, as well as in the detailed flows presented in the =20 companion XCON call flows draft. As to the password, see the answer to your previous comment. > > =09Section 6.3.6 states that the XCON-USERID could be an > administrator or some other non conference participating user > =09of the ccmp server. In this case, the password field in the > request would be that of the administrator and would have nothing to > =09do with the conferences he/she is about to provision. > > =09So to summarise: The request password field may be a conference > password but it also may be some other piece of info to authenticate > =09the client issuing the command. [spromano] The "password" field is optional. Again, we look at it as =20 being strictly related to the conference, as per the =20 element of the data model. We have not taken =20 into account the case of a non-participating administrator who is =20 willing to use such field to enter the conferencing system and carry =20 out CCMP-based operations. Stated in different terms, we did not face =20 the issue of authenticating the system administrator via a field other =20 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 > =09A filter mechanism needs to be specified here to allow clients > only retreieve a subset of conferences based on search crieteria. > =09e.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 =20 confsRequest and blueprintsRequest messages. Our idea would be the =20 following (you'll find it in the upcoming versions of the draft), with =20 reference, e.g. to the former message: =09 =09=09 =09=09=09 =09=09=09=09 =09=09=09 =09=09 =09 As you can see, we propose to add an optional "xpathFilter" element =20 (of a generic "xs:string" type) to the message, in order to allow the =20 server to appropriately filter out unwanted information before sending =20 back to the client the list of conferences. Example --> retrieve just registered conferences: xpathFilter=3D"/info:conference-info[info:conference-state/info:active=3D'fa= lse']"; What is your feeling about such proposal? Do you think it does the =20 job? Or should we go for a finer-grained definition of the new element =20 (which might be bound, for example, to sharply represent an xpath =20 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 in > confUserID which would be wrong in this case.... [spromano] The xcon-userid of the target user is contained inside the =20 "entity" attribute of the userRequest/retrieve message. Example: Alice is administrator and wants to retrieve Bob's info, with =20 Bob being a participant in conference 8977777. Alice sends the =20 following message via the CCMP: xcon-userid:alice@example.com xcon:8977777@example.com retrieve Inside the response, ?confUserId? contains =20 ?xcon-userid:alice@example.com?, whereas the ?userInfo? parameter =20 carries back Bob's information. > > 6.3.4. confRequest and confResponse > =09This is a general question. If one develops a CCMP based > provisioning client to simply provision conferences on the server, > =09they are not interested in the conference runtime parameters of > conferences like the entities. Not a big deal for the client, > =09they can simply ignore this info, but it is a significent > performance hit for the CCMP server to provide up to date conference > runtime > =09info to clients... I think we need some mechanism to avoid this > overhead for clients that do not need this info. [spromano] If one wants to retrieve general information about =20 available conferences, he can issue a confsRequest message, whose =20 response will contain high-level information (in particular, all that =20 can be inserted in a "uri-type" element -- display-text, uri, purpose, =20 etc. --). A drill-down query can be issued by sending a confRequest =20 message associated with a specific conference object. In principle, =20 the entire conference document is sent back to the client, even though =20 the choice of what kind of information to provide (e.g. users list, =20 passwords, etc.) is completely implementation-dependent. The only =20 requirement is for the server to send back an xml element compliant =20 with the "conference-type" element of the data model. Once again, a =20 policy-based approach might be put into place to properly =20 identify/discriminate "who is trying to do what" and (re)act =20 accordingly. Finally, if a user wants to retrieve fragments of a conference object =20 (e.g. info about a certain user, all users, sidebars, etc), she can =20 exploit the ad-hoc conceived messages made available by the protocol. =20 As you will have noticed, when deciding what messages to define for =20 the CCMP, we tried to strike the balance between granularity of the =20 protocol and its complexity. > > 10 HTTP Transport > =09Link '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 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 > directories. > This draft is a work item of the Centralized Conferencing Working Group > of the IETF. > > > =09Title : Centralized Conferencing Manipulation Protocol > =09Author(s) : M. Barnes, et al. > =09Filename : draft-ietf-xcon-ccmp-04.txt > =09Pages : 98 > =09Date : 2009-11-11 > > The Centralized Conferencing Manipulation Protocol (CCMP) can create, > retrieve, change and delete objects describing a centralized conference, > such as state and capabilities of the conference, participants, and > their roles. The conference information is contained in XML documents > and fragments conforming to the centralized conferencing data model > schema. Even though the goal of the CCMP is to appropriately manage > conference state, the mechanisms upon which the protocol itself is built > are based on a state-less request/response paradigm. Conferencing > clients send requests to 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 > 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 May 16, 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-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 > implementation to automatically retrieve the ASCII version of the > 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 spromano@unina.it Mon Dec 21 09:54:46 2009 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 186163A6A74 for ; Mon, 21 Dec 2009 09:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.428 X-Spam-Level: ** X-Spam-Status: No, score=2.428 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWR+O5Qjkh2e for ; Mon, 21 Dec 2009 09:54:45 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id E89F83A6A83 for ; Mon, 21 Dec 2009 09:54:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nBLHrdAW029508; Mon, 21 Dec 2009 18:53:40 +0100 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 21 Dec 2009 18:53:39 +0100 Message-ID: <20091221185339.3hmyxu8tcgg4c08c@webmail.unina.it> Date: Mon, 21 Dec 2009 18:53:39 +0100 From: spromano@unina.it To: yguo2 References: In-Reply-To: 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 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: Mon, 21 Dec 2009 17:54:46 -0000 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 =20 document (which we are on the point of submitting in its latest =20 version), section 6.4, "Muting a party". I don't know if it is useful =20 to replicate it in the CCMP document. What is your opinion about that? > > 2 If the conference system consists of general purpose conference room whi= ch > is bound to any user, then how does CCMP work in this situation? > Specifically, how would CCMP model the scenario: =B3room San Jose wants to > invite room New York to a conference=B2? [spromano] CCMP does not envisage the possibility of "natively" =20 inviting a conference to another conference. What can be done is for a =20 user in a conference to retrieve the list of users in the other =20 conference (usersRequest/retrieve) and immediately thereafter issue a =20 usersRequest/update message aimed at modifying the allowed users list =20 of the first conference (by stating that the newly invited users must =20 be contacted in "dial-out" mode). Alternatively, we might create a sidebar (which would be in all =20 respects a clone of the first conference) and invite all users of the =20 second conference as participants in it. 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 root@core3.amsl.com Wed Dec 23 20:45:01 2009 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DE1EA3A68AF; Wed, 23 Dec 2009 20:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091224044501.DE1EA3A68AF@core3.amsl.com> Date: Wed, 23 Dec 2009 20:45:01 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-05.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 04:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-05.txt Pages : 102 Date : 2009-12-23 The Centralized Conferencing Manipulation Protocol (CCMP) can create, retrieve, change and delete objects describing a centralized conference, such as state and capabilities of the conference, participants, and their roles. The conference information is contained in XML documents and fragments conforming to the centralized conferencing data model schema. Even though the goal of the CCMP is to appropriately manage conference state, the mechanisms upon which the protocol itself is built are based on a state-less request/response paradigm. Conferencing clients send requests to 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 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 June 27, 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-ccmp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-ccmp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-23203959.I-D@ietf.org> --NextPart-- From mary.barnes@nortel.com Wed Dec 23 20:50:16 2009 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 DE3AF3A68FA for ; Wed, 23 Dec 2009 20:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.686 X-Spam-Level: X-Spam-Status: No, score=-6.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyHuobUvSR9V for ; Wed, 23 Dec 2009 20:50:15 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A226D3A68FD for ; Wed, 23 Dec 2009 20:50:15 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBO4nq921577; Thu, 24 Dec 2009 04:49:53 GMT 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, 23 Dec 2009 22:50:57 -0600 Message-ID: In-Reply-To: <20091224044501.DE1EA3A68AF@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-xcon-ccmp-05.txt Thread-Index: AcqEU+VLJ5Kj5os9SZqMC0DCa0U2TAAAHF/w References: <20091224044501.DE1EA3A68AF@core3.amsl.com> From: "Mary Barnes" To: Cc: xcon-chairs@tools.ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-05.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 04:50:17 -0000 Hi all, We have updated the document to address recent comments and issue resolution as discussed at IETF-76. The following summarizes the changes: - Added versioning. - Added a string to response codes. - Removed the "modified" response code. - Added filtering for conference info in responses. - Editorial clarifications and nits. The document should be ready for WGLC. Thanks, Mary and Simon=20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 23, 2009 10:45 PM To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: I-D Action:draft-ietf-xcon-ccmp-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-05.txt Pages : 102 Date : 2009-12-23 The Centralized Conferencing Manipulation Protocol (CCMP) can create, retrieve, change and delete objects describing a centralized conference, such as state and capabilities of the conference, participants, and their roles. The conference information is contained in XML documents and fragments conforming to the centralized conferencing data model schema. Even though the goal of the CCMP is to appropriately manage conference state, the mechanisms upon which the protocol itself is built are based on a state-less request/response paradigm. Conferencing clients send requests to 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 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 June 27, 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-ccmp-05.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 root@core3.amsl.com Tue Dec 29 04:45:02 2009 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4879A3A68EA; Tue, 29 Dec 2009 04:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091229124502.4879A3A68EA@core3.amsl.com> Date: Tue, 29 Dec 2009 04:45:02 -0800 (PST) Cc: xcon@ietf.org Subject: [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: Tue, 29 Dec 2009 12:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-examples-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-examples-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-29044233.I-D@ietf.org> --NextPart--