http:= //tools.ietf.org/wg/xcon/draft-levin-xcon-cccp-04.txt

The = main change is=20 an addition of section 6 detailing some of the design rationale behind = the CCCP=20 protocol design. Looking forward to discussion of the pros and cons of = each of=20 the proposed designs.

------_=_NextPart_001_01C6122A.8CF39BDB-- --===============1144205052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1144205052==-- From xcon-bounces@ietf.org Fri Jan 13 18:52:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYiy-0004RT-HQ; Fri, 13 Jan 2006 18:52:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYiw-0004R8-Aq for xcon@megatron.ietf.org; Fri, 13 Jan 2006 18:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22870 for ; Fri, 13 Jan 2006 18:51:26 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExYqL-0002g8-8q for xcon@ietf.org; Fri, 13 Jan 2006 19:00:29 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Jan 2006 15:52:40 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 15:51:53 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 15:51:53 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 15:51:53 -0800 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 Subject: RE: URGENT REMINDER: [XCON] Conference Control: Path Forward Date: Fri, 13 Jan 2006 15:51:51 -0800 Message-ID: In-Reply-To: <438B82FE.4080806@estacado.net> Thread-Topic: URGENT REMINDER: [XCON] Conference Control: Path Forward thread-index: AcX0anPl0RYOuJqsTbW+Y3nLVXMSEQkMRL+w From: "Sean Olson" To: "Adam Roach" , "Adam Roach" X-OriginalArrivalTime: 13 Jan 2006 23:51:53.0153 (UTC) FILETIME=[54190B10:01C6189C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org I haven't seen any discussion so far about the protocol submissions: - Henning's SOAP proposal (http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-0 0.html)=20 - Cullen/Oscar's CSCP proposal (http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt) - Our CCCP proposal (http://tools.ietf.org/wg/xcon/draft-levin-xcon-cccp-04.txt) What are the next steps for evaluating these submissions? -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: Monday, November 28, 2005 2:22 PM To: Adam Roach Cc: XCON-IETF Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward [as chair] If anyone in the working group cares about the protocol we end up selecting for conference control -- or, indeed, finishing our work at all -- they are strongly advised to participate in this conversation. If we can't get any participation around our deliverables, we really have no choice but to shut the working group down. /a Adam Roach wrote: > [as chair] > > In Vancouver, the XCON chairs outlined a process by which we would=20 > attempt to meet our proposed milestones. This message summarizes that=20 > process, as amended by the input we received from the XCON participants. > > 1. Proposals for candidates for the Conference Control Protocol (CCP) > must be submitted in internet-draft format no later than December > 31st, 2005. The draft does not need to be complete; however, there > must be sufficient detail to make clear how the proposed protocol > would be used to modify information in both the Common Conference > Information and Conference Template. (See > draft-ietf-xcon-framework for definitions). > > 2. All protocols to be considered additionally need a brief message > from an author and/or proponent of the corresponding draft that > explains the design decisions taken in the design of the protocol, > as well as a summary of strengths and drawbacks of the approach. > Such proponents should contact the XCON chairs to coordinate. > * Such proponents should discuss implementation lessons, if > available, around using their proposed protocol to modify > the Common Conference Information. > * Separately, such proponents should additionally discuss > implementation lessons, if available, around using their > proposed protocol to modify the Conference Template. > > 3. Starting in early January, the chairs will call for discussion on > the mailing list to gauge the overall direction the working group > wishes to proceed. > > 4. Between now and January, interested parties should discuss their > requirements around the CCP on the mailing list. These discussions > should assist in coming to consensus on the CCP that XCON will use. > > Hopefully, the result of the January discussions will resolve to a=20 > single approach (either by selection of one of the proposals or by=20 > combining one or more of them into a unified proposal). > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 13 19:39:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExZSH-0008NQ-Lb; Fri, 13 Jan 2006 19:39:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExZSG-0008NI-Cv for xcon@megatron.ietf.org; Fri, 13 Jan 2006 19:39:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26219 for ; Fri, 13 Jan 2006 19:38:18 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExZZe-0004Qa-4x for xcon@ietf.org; Fri, 13 Jan 2006 19:47:20 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k0E0Z8W05604; Fri, 13 Jan 2006 19:35:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: URGENT REMINDER: [XCON] Conference Control: Path Forward Date: Fri, 13 Jan 2006 18:38:47 -0600 Message-ID: Thread-Topic: URGENT REMINDER: [XCON] Conference Control: Path Forward Thread-Index: AcX0anPl0RYOuJqsTbW+Y3nLVXMSEQkMRL+wAAE4cJA= From: "Mary Barnes" To: "Sean Olson" , "Adam Roach" , "Adam Roach" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Sean, Thanks for re-starting this discussion. There's actually a 2nd SOAP proposal that I submitted right near the deadline that appeared on Jan 3rd: http://www.ietf.org/internet-drafts/draft-barnes-xcon-ccmp-00.txt This proposal is very preliminary as there's several TBD sections, but I think it could be easily merged with Henning's COMP proposal as the approaches are quite similar. I think what we should be doing now is debating the advantages and disadvantages of each of the proposals. I had a chart in the package I presented at IETF-64 during the framework discussion (chart 10): http://www.softarmor.com/xcon/meets/ietf64/agenda.pl This evaluation looked at some of the protocol motherhood statements and I tried to work through a more detailed set of requirements, but kept coming back to fundamentals such as: 1. Same protocol for data manipulation and conference operations. 2. Based on a protocol that's already implemented (or needing to be implemented for other functionality) by clients.=20 3. Affinity with the data model to reduce the complexity. =20 I do think one of the difficulties is that we need to agree fundamental requirements or priority of some of the motherhood requirements to see which protocol is most suitable. In considering the 3 protocols on the table (considering Henning's COMP and CCMP as the same), I would still come up with a similar analysis as that chart 10, which I'll summarize below (and apolgize in advance if the formatting is funky): CCCP CSCP CCMP/COMP -------------------------------------------------------- Based on XML Yes No No (but WSDL can be derived from XML) Existing No Yes(BFCP) Yes protocol Event Yes Yes (?) No (plan to use SIP) Notification Mechanism=20 Compact No Yes No Efficient Yes Yes Yes Easy to Yes Yes Yes Implement=20 And, I'm afraid this doesn't help much. I think any of the approaches could work. Of course, CCCP has been proven to work in one implementation, but SOAP has been successfully implemented in many implementations, albeit not for this application. And, I think the compact nature of CSCP might be appealing to the wireless folks.=20 Obviously, my preference is for the COMP/CCMP approach. Mary -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Sean Olson Sent: Friday, January 13, 2006 5:52 PM To: Adam Roach; Adam Roach Cc: XCON-IETF Subject: RE: URGENT REMINDER: [XCON] Conference Control: Path Forward I haven't seen any discussion so far about the protocol submissions: - Henning's SOAP proposal (http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-0 0.html)=20 - Cullen/Oscar's CSCP proposal (http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt) - Our CCCP proposal (http://tools.ietf.org/wg/xcon/draft-levin-xcon-cccp-04.txt) What are the next steps for evaluating these submissions? -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: Monday, November 28, 2005 2:22 PM To: Adam Roach Cc: XCON-IETF Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward [as chair] If anyone in the working group cares about the protocol we end up selecting for conference control -- or, indeed, finishing our work at all -- they are strongly advised to participate in this conversation. If we can't get any participation around our deliverables, we really have no choice but to shut the working group down. /a Adam Roach wrote: > [as chair] > > In Vancouver, the XCON chairs outlined a process by which we would=20 > attempt to meet our proposed milestones. This message summarizes that=20 > process, as amended by the input we received from the XCON participants. > > 1. Proposals for candidates for the Conference Control Protocol (CCP) > must be submitted in internet-draft format no later than December > 31st, 2005. The draft does not need to be complete; however, there > must be sufficient detail to make clear how the proposed protocol > would be used to modify information in both the Common Conference > Information and Conference Template. (See > draft-ietf-xcon-framework for definitions). > > 2. All protocols to be considered additionally need a brief message > from an author and/or proponent of the corresponding draft that > explains the design decisions taken in the design of the protocol, > as well as a summary of strengths and drawbacks of the approach. > Such proponents should contact the XCON chairs to coordinate. > * Such proponents should discuss implementation lessons, if > available, around using their proposed protocol to modify > the Common Conference Information. > * Separately, such proponents should additionally discuss > implementation lessons, if available, around using their > proposed protocol to modify the Conference Template. > > 3. Starting in early January, the chairs will call for discussion on > the mailing list to gauge the overall direction the working group > wishes to proceed. > > 4. Between now and January, interested parties should discuss their > requirements around the CCP on the mailing list. These discussions > should assist in coming to consensus on the CCP that XCON will use. > > Hopefully, the result of the January discussions will resolve to a=20 > single approach (either by selection of one of the proposals or by=20 > combining one or more of them into a unified proposal). > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Jan 15 10:24:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9jc-0004Yh-4J; Sun, 15 Jan 2006 10:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9jQ-0004WZ-01 for xcon@megatron.ietf.org; Sun, 15 Jan 2006 10:23:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05455 for ; Sun, 15 Jan 2006 10:22:22 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey9r6-0000SG-MX for xcon@ietf.org; Sun, 15 Jan 2006 10:31:46 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0FFLTGt027371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jan 2006 10:23:38 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k0FFLPhn002256; Sun, 15 Jan 2006 10:21:26 -0500 Message-ID: <43C95480.40204@cs.columbia.edu> Date: Sat, 14 Jan 2006 14:44:00 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mary Barnes Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Spam-Score: 0.4 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Adam Roach , Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org > There's actually a 2nd SOAP proposal that I submitted right near the > deadline that appeared on Jan 3rd: > http://www.ietf.org/internet-drafts/draft-barnes-xcon-ccmp-00.txt > > This proposal is very preliminary as there's several TBD sections, but I > think it could be easily merged with Henning's COMP proposal as the > approaches are quite similar. That's certainly my intent and hope. > 1. Same protocol for data manipulation and conference operations. > 2. Based on a protocol that's already implemented (or needing to be > implemented for other functionality) by clients. Or, possibly, protocol*s*, since some proposals use more than one (SIP for event notification, for example). > 3. Affinity with the data model to reduce the complexity. > > In considering the 3 protocols on the table (considering Henning's COMP > and CCMP as the same), I would still come up with a similar analysis as > that chart 10, which I'll summarize below (and apolgize in advance if > the formatting is funky): > > CCCP CSCP CCMP/COMP > -------------------------------------------------------- > Based on XML Yes No No (but WSDL can be derived from > XML) I would consider CCMP/COMP as based on XML, in that the on-the-wire format is XML. > > Existing No Yes(BFCP) Yes > protocol > > Event Yes Yes (?) No (plan to use SIP) > Notification > Mechanism > > Compact No Yes No In general, if XML is used over TLS, TLS will do gzip-style compression, probably reducing the packet size footprint considerably. > > Efficient Yes Yes Yes > > Easy to Yes Yes Yes > Implement > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Jan 17 12:25:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyua6-0007Rq-Ah; Tue, 17 Jan 2006 12:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyua5-0007Rf-4c for xcon@megatron.ietf.org; Tue, 17 Jan 2006 12:25:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02349 for ; Tue, 17 Jan 2006 12:23:52 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyuiA-00087J-DL for xcon@ietf.org; Tue, 17 Jan 2006 12:33:43 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4BBC86D2; Tue, 17 Jan 2006 18:25:02 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 18:25:02 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 18:25:01 +0100 Received: from [131.160.126.17] (rvi2-126-17.lmf.ericsson.se [131.160.126.17]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AB73B284C; Tue, 17 Jan 2006 19:25:01 +0200 (EET) Message-ID: <43CD286B.3000808@ericsson.com> Date: Tue, 17 Jan 2006 19:24:59 +0200 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward References: <43C95480.40204@cs.columbia.edu> In-Reply-To: <43C95480.40204@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2006 17:25:01.0949 (UTC) FILETIME=[F2CB62D0:01C61B8A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Adam Roach , Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi Henning, > In general, if XML is used over TLS, TLS will do gzip-style compression, > probably reducing the packet size footprint considerably. out of curiosity, I thought TLS compression was not widely implemented. Do you know whether or not that is actually the case? Thanks, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Jan 17 12:55:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyv3K-0007hw-CB; Tue, 17 Jan 2006 12:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyv3J-0007hn-KR for xcon@megatron.ietf.org; Tue, 17 Jan 2006 12:55:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04718 for ; Tue, 17 Jan 2006 12:54:04 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvBT-0000gw-FE for xcon@ietf.org; Tue, 17 Jan 2006 13:03:56 -0500 Received: from lion.cs.columbia.edu (IDENT:tO5IP0vRwxfniStOo6hx+kJWCAok/PpU@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0HHpNGt001438 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 17 Jan 2006 12:55:18 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0HHpMnE029514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jan 2006 12:51:22 -0500 Message-ID: <43CD2E0F.1050406@cs.columbia.edu> Date: Tue, 17 Jan 2006 12:49:03 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward References: <43C95480.40204@cs.columbia.edu> <43CD286B.3000808@ericsson.com> In-Reply-To: <43CD286B.3000808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Adam Roach , Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org I'm not a TLS expert, but I did find that GNU TLS seems to implement something related: http://www.gnu.org/software/gnutls/manual/html_node/Compression-algorithms-used-in-the-record-layer.html http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html has some related information and indicates that this maybe a transient problem. http://www.openssl.org/news/news.html mentionds Changed the ZLIB compression method to be stateful. which does indicate compression support. Somebody with first-hand knowledge probably should pipe up here. Gonzalo Camarillo wrote: > Hi Henning, > >> In general, if XML is used over TLS, TLS will do gzip-style >> compression, probably reducing the packet size footprint considerably. > > out of curiosity, I thought TLS compression was not widely implemented. > Do you know whether or not that is actually the case? > > Thanks, > > Gonzalo > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Jan 24 00:06:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GNo-0006iA-PQ; Tue, 24 Jan 2006 00:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GNm-0006i5-Ef for xcon@megatron.ietf.org; Tue, 24 Jan 2006 00:06:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06158 for ; Tue, 24 Jan 2006 00:04:48 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1GXG-00013v-Hg for xcon@ietf.org; Tue, 24 Jan 2006 00:16:06 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Jan 2006 21:06:08 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 21:05:57 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 17:53:23 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 17:53:23 -0800 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 Subject: RE: URGENT REMINDER: [XCON] Conference Control: Path Forward Date: Mon, 23 Jan 2006 17:53:23 -0800 Message-ID: In-Reply-To: <43CD2E0F.1050406@cs.columbia.edu> Thread-Topic: URGENT REMINDER: [XCON] Conference Control: Path Forward thread-index: AcYbj198QuHej3cGTVebTib/1w78QQE+T6Jw From: "Sean Olson" To: "Henning Schulzrinne" , "Gonzalo Camarillo" X-OriginalArrivalTime: 24 Jan 2006 01:53:23.0190 (UTC) FILETIME=[F56DE960:01C62088] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org The implementation of TLS in the Windows OS (Schannel) does not support compression. Application-level compression may be more appropriate anyways for XML-based protocols. DEFLATE should do a good enough job, but I'd be curious to hear other opinions. -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, January 17, 2006 9:49 AM To: Gonzalo Camarillo Cc: Adam Roach; Adam Roach; XCON-IETF Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward I'm not a TLS expert, but I did find that GNU TLS seems to implement something related: http://www.gnu.org/software/gnutls/manual/html_node/Compression-algorith ms-used-in-the-record-layer.html http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html has some related information and indicates that this maybe a transient problem. http://www.openssl.org/news/news.html mentionds Changed the ZLIB compression method to be stateful. which does indicate compression support. Somebody with first-hand knowledge probably should pipe up here. Gonzalo Camarillo wrote: > Hi Henning, >=20 >> In general, if XML is used over TLS, TLS will do gzip-style=20 >> compression, probably reducing the packet size footprint considerably. >=20 > out of curiosity, I thought TLS compression was not widely implemented.=20 > Do you know whether or not that is actually the case? >=20 > Thanks, >=20 > Gonzalo >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Jan 24 03:40:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1JjX-00057b-24; Tue, 24 Jan 2006 03:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1JjV-00057P-6C for xcon@megatron.ietf.org; Tue, 24 Jan 2006 03:40:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19840 for ; Tue, 24 Jan 2006 03:39:26 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Jsv-00086l-Gb for xcon@ietf.org; Tue, 24 Jan 2006 03:50:47 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 55A5D6F9 for ; Tue, 24 Jan 2006 09:40:36 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 09:40:36 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 09:40:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jan 2006 09:40:35 +0100 Message-ID: Thread-Topic: New version of CSCP draft Thread-Index: AcYSKsUfSXsE2xgURaOr6R2I6JBtbQOlWzcA From: "Oscar Novo $JO/LMF$" To: X-OriginalArrivalTime: 24 Jan 2006 08:40:36.0406 (UTC) FILETIME=[D8C2CD60:01C620C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [XCON] New version of CSCP draft X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1200257345==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1200257345== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C620C1.7FDB6720" This is a multi-part message in MIME format. ------_=_NextPart_001_01C620C1.7FDB6720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We would like to notify the new version of the CSCP draft. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-03.txt Here's an overall summary of the changes: - Definition of new operations: Section 9.1 "Creation of a conference" and Section 9.2 "Termination of a conference"=20 - Definition of new attributes (Section 8: TEMPLATE-ID) =20 - Definition of new error values of the protocol - In Section 11 (Examples) added additional examples (Creation of a conference, Modification of a conference, Destruction of a conference) and additional text explaining the example Cheers, Oscar ------_=_NextPart_001_01C620C1.7FDB6720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

We would like to notify the new version = of the CSCP=20 draft. Until it appears in the archives, you can fetch it = from:

http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-03.txt

Here's an overall summary of the = changes:

- = Definition of new operations: Section 9.1 "Creation of a = conference"=20 and Section 9.2 "Termination of a=20 conference"

- = Definition of new=20 attributes (Section 8: TEMPLATE-ID)

- = Definition of new error values of the=20 protocol

- In=20 Section 11 (Examples) added additional examples (Creation of a = conference,=20 Modification of a conference, Destruction of a=20 conference) and additional text explaining the = example

Cheers,

Oscar

------_=_NextPart_001_01C620C1.7FDB6720-- --===============1200257345== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1200257345==-- From xcon-bounces@ietf.org Thu Jan 26 09:42:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28KV-0004EQ-VQ; Thu, 26 Jan 2006 09:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28KS-0004Ct-TH for xcon@megatron.ietf.org; Thu, 26 Jan 2006 09:42:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21105 for ; Thu, 26 Jan 2006 09:40:52 -0500 (EST) Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F28UM-0006lm-Bp for xcon@ietf.org; Thu, 26 Jan 2006 09:52:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] New version of CSCP draft Date: Thu, 26 Jan 2006 16:42:14 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03215562@IsrExch01.israel.polycom.com> Thread-Topic: [XCON] New version of CSCP draft Thread-Index: AcYSKsUfSXsE2xgURaOr6R2I6JBtbQOlWzcAAHBFCmA= From: "Even, Roni" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0562385082==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0562385082== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62286.B33FBADB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62286.B33FBADB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I read the draft and would like to give the following feedback that includes questions and comments. =20 1. The document is using the conference event package after the conference creation in order to get the elements IDs. My understanding so far is that a UA subscribes to a conference that is running now and not to one that is created and may run later. I see this as a major issue since the whole solution is based on it. It is not only issue of when you can subscribe to a conference state but also about extending the conference event package to include all the elements and attributes that are needed to create conferences which are not there. =20 2. In section 8 you sort of define the template, I suggest referring to the framework document. =20 3. In section 9.1 second paragraph - "The creator sets inside the AddConferenceRequest the name of the conference" suggest using display name. =20 4. When creating a conference, how does the user learn the urn of the templates he can use. =20 5. In section 9.1 "If the AddConferenceRequest refers to a conference which does already exist in the server," - how can it happen since the conference ID in the header must be zero. The display name is not unique as far as I understand. =20 6. In 9.1 "If the AddConferenceRequest is successful, the server responds with a AddConferenceAck, which includes the URI of the conference created inside the ELEMENT-ID." It si not the conference URI but the conference ID. The same comment is for section 9.2 in two places -the element-id indicates the conference ID and not the URI. =20 7. In section 9.4 you are talking about setting attributes value. The second paragraph talks about retrieving - this is probably a cut and paste from 9.3. =20 8. In section 10=20 8. "It is RECOMMENDED that once an ELEMENT-ID value is used in an element within a conference, the same ELEMENT-ID value is not used in the same conference again in a different element." I think RECOMMENDED is too weak, according to section 5 the element id uniquely identify an element withing a conference. =20 9. In the example in section 11.1 the addConferenceAck message returns Conference ID: 000. Shouldn't it be the same as the ELEMENT-ID. =20 10. I noticed that section 12 talks about correlation with the conference event package. Just note that the dial-out-list in the example of section 11.3 is not a child element of users. There is no dial-out list in the event package, since this is not a state. There is information inside the endpoint element if this was a dial out or dial in call. =20 11. Nit - section 9.5 first line - add an element instead of add and element. =20 =20 =20 Roni Even ------_=_NextPart_001_01C62286.B33FBADB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read the draft and would like to = give the following feedback that includes questions and = comments.

1. = The document is using the conference event package after the conference creation in order to get the elements IDs. = My understanding so far is that a UA subscribes to a conference that is = running now and not to one that is created and may run later. I see this = as a major issue since the whole solution is based on it. It is not only = issue of when you can subscribe to a conference state but also about extending = the conference event package to include all the elements and attributes that = are needed to create conferences which are not = there.

2. = In section 8 you sort of define the = template, I suggest referring to the framework document.

3. = In section 9.1 second paragraph - = “The creator sets inside the AddConferenceRequest the name of the = conference” suggest using display name.

4. = When creating a conference, how does the = user learn the urn of the templates he can = use.

5. = In section 9.1 “If the = AddConferenceRequest refers to a conference which does already exist in the server,” = – how can it happen since the conference ID in the header must be zero. = The display name is not unique as far as I = understand.

6. = In 9.1 “If the = AddConferenceRequest is successful, the server responds with a AddConferenceAck, which = includes the URI of the conference created inside the ELEMENT-ID.” It si not = the conference URI but the conference ID. The same comment is for section 9.2 in = two places -the element-id indicates the conference ID and not the = URI.

7. = In section 9.4 you are talking about = setting attributes value. The second paragraph talks about retrieving – this is = probably a cut and paste from 9.3.

8. In section 10

8. “It is RECOMMENDED that once an = ELEMENT-ID value is used in an element within a conference, the same ELEMENT-ID = value is not used in the same conference again in a different element.” I = think RECOMMENDED is too weak, according to section 5 the element id uniquely identify an element withing a = conference.

9. In the example in section 11.1 the addConferenceAck = message returns Conference ID: 000. Shouldn’t it be the same as the = ELEMENT-ID.

10. I noticed that section 12 talks about = correlation with the conference event package. Just note that the dial-out-list in = the example of section 11.3 is not a child element of users. There is no = dial-out list in the event package, since this is not a state. There is = information inside the endpoint element if this was a dial out or dial in = call.

11. Nit – section 9.5 first line = – add an element instead of add and = element.

Roni = Even

------_=_NextPart_001_01C62286.B33FBADB-- --===============0562385082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0562385082==-- From xcon-bounces@ietf.org Fri Jan 27 05:01:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2QQL-0006op-PO; Fri, 27 Jan 2006 05:01:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2QQJ-0006oB-QQ for xcon@megatron.ietf.org; Fri, 27 Jan 2006 05:01:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22631 for ; Fri, 27 Jan 2006 05:00:10 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly29b.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2QaQ-0008NK-Pc for xcon@ietf.org; Fri, 27 Jan 2006 05:12:12 -0500 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly29b.srv.mailcontrol.com (MailControl) with ESMTP id k0RA1O8u028266; Fri, 27 Jan 2006 10:01:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Jan 2006 10:01:24 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118904@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQ== From: "Chris Boulton" To: X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.66.0.139 X-Spam-Score: 0.8 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: ajohnston@tello.com, Adam Roach Subject: [XCON] Conference Control X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0554492707==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0554492707== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62328.A1D20688" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62328.A1D20688 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.=20=20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C62328.A1D20688 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Just wanted to generate some discussion relating = to the recent Conference Control submissions. I would like to begin by thank= ing all the relevant parties for the effort contributed before Christmas. =

While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed = all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may a= lready know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my prefere= nce was being swayed (purely selfish :-) by ‘who exactly will be a confer= ence client manipulating Conference Objects?’ As an application serv= er vendor who’s product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as C= CCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing suppo= rt for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure= to link to our clients.

It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP an= d a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementa= tion and ability to advertise capabilities to a Conference Client I personally f= eel that this is the best solution to make XCON appealing to a wide variety of architectures.

I’m going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive mee= ting to comment on mails such as this over the coming months.

Best Regards,

Chris Boulton.

Information contained in t= his e-mail and any attachments are intended for the use of the addressee on= ly, and may contain confidential information of Ubiquity Software Corporati= on. All unauthorized use, disclosure or distribution is strictly prohibited= . If you are not the addressee, please notify the sender immediately = and destroy all copies of this email. Unless otherwise expressly agre= ed in writing signed by an officer of Ubiquity Software Corporation, nothin= g in this communication shall be deemed to be legally binding. Thank-you ------_=_NextPart_001_01C62328.A1D20688-- --===============0554492707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0554492707==-- From xcon-bounces@ietf.org Fri Jan 27 09:28:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Uah-00042x-VW; Fri, 27 Jan 2006 09:28:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Uaf-00042j-5j for xcon@megatron.ietf.org; Fri, 27 Jan 2006 09:28:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12785 for ; Fri, 27 Jan 2006 09:27:08 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Ukp-0000Pv-GD for xcon@ietf.org; Fri, 27 Jan 2006 09:39:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F2UaU-0001bT-Nu; Fri, 27 Jan 2006 08:28:31 -0600 From: "Brian Rosen" To: "'Chris Boulton'" , Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 09:26:39 -0500 Message-ID: <02b401c6234d$b298f360$651f0a0a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwg In-Reply-To: <45730E094814E44488F789C1CDED27AE03118904@gbnewp0758m.eu.ubiquity.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.6 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: ajohnston@tello.com, 'Adam Roach' X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766616163==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0766616163== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B5_01C62323.C9C2EB60" This is a multi-part message in MIME format. ------=_NextPart_000_02B5_01C62323.C9C2EB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there. Brian _____ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control Hi All, Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. Best Regards, Chris Boulton. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you ------=_NextPart_000_02B5_01C62323.C9C2EB60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not opposed to having two = bindings to the same interface, but I would not want to see two interfaces. = That means the models, data structures, operations, errors, etc would have to = be identical, with only transport being different. I’m not sure = that would be particularly interesting to you.

Also, could you clarify your = statements on CSCP? What you said was “it may be = likely, as it is not mandatory, that BFCP be implemented in the solution and so = developing support for something like CSCP would be seen as a burden”. = I can’t figure out if you WILL implement BFCP, and thus CSCP is easy, or you = won’t implement BFCP because it’s not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less = work from there. =

Brian

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Friday, January 27, = 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: [XCON] = Conference Control

Hi All,

Just wanted to generate some discussion = relating to the recent Conference Control submissions. I would like to begin = by thanking all the relevant parties for the effort contributed before Christmas.

While I realise that the thoughts conveyed in = this mail are a little controversial, I thought I would poke my head up into = the firing line in attempt to stimulate some discussion. I have = reviewed all of the proposals and will be providing questions and feedback in = individual mails. This mail is an attempt to discuss some architectural = decisions that I personally feel are equally as important. As some of you = may already know, I am a supporter of the SOAP proposals (Henning, myself = and Mary) that are currently being worked on. This led me to realise that my = preference was being swayed (purely selfish :-) by ‘who exactly will be a = conference client manipulating Conference Objects?’ As an application = server vendor who’s product very much utilises web services. SOAP seems = the obvious choice. From a handset vendor I can also see that = proposals such as CCCP and CSCP are more appealing. As an application server = offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing = support for something like CSCP would be seen as a burden, especially as we already = have a web services interface that provides all the relevant infrastructure to = link to our clients.

It is for these reasons that I was pondering = the prospect of XCON allowing both a handset friendly interface such as CSCP = and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two = interfaces is not ideal, but as long as we are careful in our rules on minimal = implementation and ability to advertise capabilities to a Conference Client I = personally feel that this is the best solution to make XCON appealing to a wide variety = of architectures.

I’m going to duck now and wait for = incoming bullets but on a serious note I strongly appeal to all who are = interested on making Dallas a productive meeting to comment on mails such as this over the coming = months.

Best Regards,

Chris Boulton.

Information contained in = this e-mail and any attachments are intended for the use of the addressee = only, and may contain confidential information of Ubiquity Software Corporation. = All unauthorized use, disclosure or distribution is strictly = prohibited. If you are not the addressee, please notify the sender immediately and = destroy all copies of this email. Unless otherwise expressly agreed in writing = signed by an officer of Ubiquity Software Corporation, nothing in this = communication shall be deemed to be legally binding. Thank-you =

------=_NextPart_000_02B5_01C62323.C9C2EB60-- --===============0766616163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0766616163==-- From xcon-bounces@ietf.org Fri Jan 27 10:16:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VLB-0000Aq-RU; Fri, 27 Jan 2006 10:16:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VL9-00009m-LO for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:16:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18118 for ; Fri, 27 Jan 2006 10:15:10 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VVH-0002cS-0H for xcon@ietf.org; Fri, 27 Jan 2006 10:27:15 -0500 Received: from rly21b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly21b.srv.mailcontrol.com (MailControl) with ESMTP id k0RFGTI4008975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 15:16:29 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly21b.srv.mailcontrol.com (MailControl) id k0RFFtGu006626 for xcon@ietf.org; Fri, 27 Jan 2006 15:15:55 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly21b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0RFFpKb006347; Fri, 27 Jan 2006 15:15:55 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 15:12:35 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118906@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJA= From: "Chris Boulton" To: , X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.131 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4297a3b9ddbbc388d94c1425bc2288b8 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0988779780==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0988779780== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62354.1A381398" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62354.1A381398 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.=20=20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C62354.1A381398 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: 27 January 2006 14:27<= br> To: Chris Boulton; xcon@ietf= .org
Cc: ajohnston@tello.com; 'Ad= am Roach'
Subject: RE: [XCON] Conferen= ce Control

= I’m not opposed to having two bindings to the same interface, but I would not w= ant to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport bei= ng different. I’m not sure that would be particularly interesting = to you.

= Also, could you clarify your statements on CSCP? What you said was “<= /span>it may be likely, as it is not mandatory, that BFCP be implemented in the solu= tion and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement BFCP, a= nd thus CSCP is easy, or you won’t implement BFCP because it’s not mandatory and thus CSCP would be a burden. I think if you implement B= FCP then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework reads:<= /i>

F= loor control is not a mandatory mechanism for a conferencing system impleme= ntation but provides advanced media input control features for conference u= sers.

So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, j= ust having to expose a WSDL initiated web interface is preferred.=

Chris.

= Brian

=

From:= xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Friday, January 27, 20= 06 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference C= ontrol

Hi All,

Just wanted to ge= nerate some discussion relating to the recent Conference Control submissions. = ; I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I realise t= hat the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the S= OAP proposals (Henning, myself and Mary) that are currently being worked on.&nb= sp; This led me to realise that my preference was being swayed (purely selfish = :-) by ‘who exactly will be a conference client manipulating Conference Objects?’ As an application server vendor who’s product v= ery much utilises web services. SOAP seems the obvious choice. From a han= dset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services us= ing web services it may be likely, as it is not mandatory, that BFCP be impleme= nted in the solution and so developing support for something like CSCP would be = seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these r= easons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the clie= nt might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our ru= les on minimal implementation and ability to advertise capabilities to a Confer= ence Client I personally feel that this is the best solution to make XCON appeal= ing to a wide variety of architectures.

I’m going t= o duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, = and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. = If you are not the addressee, please notify the sender immediately and destroy= all copies of this email. Unless otherwise expressly agreed in writing si= gned by an officer of Ubiquity Software Corporation, nothing in this communicati= on shall be deemed to be legally binding. Thank-you

------_=_NextPart_001_01C62354.1A381398-- --===============0988779780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0988779780==-- From xcon-bounces@ietf.org Fri Jan 27 10:22:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VQW-0001O3-3k; Fri, 27 Jan 2006 10:22:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VQQ-0001Mn-J9 for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:22:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18494 for ; Fri, 27 Jan 2006 10:20:37 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VaT-0002mv-QL for xcon@ietf.org; Fri, 27 Jan 2006 10:32:41 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D664C4F0001; Fri, 27 Jan 2006 16:21:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:21:22 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:21:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] New version of CSCP draft Date: Fri, 27 Jan 2006 16:21:18 +0100 Message-ID: Thread-Topic: [XCON] New version of CSCP draft Thread-Index: AcYSKsUfSXsE2xgURaOr6R2I6JBtbQOlWzcAAHBFCmAAM5OUUA== From: "Oscar Novo $JO/LMF$" To: "Even, Roni" , X-OriginalArrivalTime: 27 Jan 2006 15:21:21.0843 (UTC) FILETIME=[54329030:01C62355] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.4 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775180714==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1775180714== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62354.F890AC76" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62354.F890AC76 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Roni,=20 =20 Thank you very much to review the CSCP draft and provide interesting = comment. I=B4ve updated the draft according to your comments number = 2,3,5,6,7,8, and 11. In the new version you will see the changes. =20 Comments to the other numbers are inline... ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Even, Roni Sent: 26. tammikuuta 2006 16:42 To: xcon@ietf.org Subject: RE: [XCON] New version of CSCP draft Hi, I read the draft and would like to give the following feedback that = includes questions and comments. =20 1. The document is using the conference event package after the = conference creation in order to get the elements IDs. My understanding = so far is that a UA subscribes to a conference that is running now and = not to one that is created and may run later. I see this as a major = issue since the whole solution is based on it. It is not only issue of = when you can subscribe to a conference state but also about extending = the conference event package to include all the elements and attributes = that are needed to create conferences which are not there. =20 [ON] But the current conference event package represents just the state = of the conference. Do you think is good idea to extend the conference = event package to support more than the state? Maybe, the CSCP protocol = should especify a mechanism to query the capabilities of the system. = Now, the CSCP protocol only allow to retrieve the attribute values. What = do you think? =20 4. When creating a conference, how does the user learn the urn of = the templates he can use. =20 [ON] this is outside the scope of the document. Anyway, I=B4ve update = the draft telling that this is outside the scope of the document and = this information can be provided by other means, such as email or the Web. =20 9. In the example in section 11.1 the addConferenceAck message = returns Conference ID: 000. Shouldn't it be the same as the ELEMENT-ID.=20 =20 [ON] I just try to keep the same behaviour in the addConferenceAck = message than in the other messages. Normally, when a server receives a = CSCP or BFCP message, it copies in the response the same Conference-ID = attribute than the one in the message receives. =20 10. I noticed that section 12 talks about correlation with the = conference event package. Just note that the dial-out-list in the = example of section 11.3 is not a child element of users. There is no = dial-out list in the event package, since this is not a state. There is = information inside the endpoint element if this was a dial out or dial = in call.=20 =20 [ON] The dial-out-list is defined in the "Common Conference Information = Data Model for Centralized Conferencing (XCON)" as an element of users. = The dial-out-list is not defined in the event package because the event = package only shows the state of the conference.=20 =20 =20 Roni Even ------_=_NextPart_001_01C62354.F890AC76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 Roni,

Thank=20 you very much to review the CSCP draft and provide interesting = comment.=20 I=B4ve updated the draft according to your comments number = 2,3,5,6,7,8, and=20 11. In the new version you will see the changes.

Comments to the other numbers are = inline...

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Even, = Roni
Sent:=20 26. tammikuuta 2006 16:42
To: xcon@ietf.org
Subject: = RE:=20 [XCON] New version of CSCP draft

Hi,

I read the = draft and=20 would like to give the following feedback that includes questions and=20 comments.

1.      =20 The document = is using=20 the conference event package after the conference creation in order to = get the=20 elements IDs. My understanding so far is that a UA subscribes to a = conference=20 that is running now and not to one that is created and may run later. = I=20 see this as a major issue since the whole solution is based on it. It is = not=20 only issue of when you can subscribe to a conference state but also = about=20 extending the conference event package to include all the elements and=20 attributes that are needed to create conferences which are not=20 there.

[ON] But the current = conference=20 event package represents just the state of the conference. Do you think is good idea to extend = the=20 conference event package to support more than the state? Maybe, the = CSCP=20 protocol should especify a mechanism to query the capabilities of the = system.=20 Now, the CSCP protocol only allow to retrieve the attribute values. What = do you=20 think?

4.      =20 When creating = a=20 conference, how does the user learn the urn of the templates he can=20 use.

[ON] this is = outside the=20 scope of the document. Anyway, I=B4ve update the draft telling = that this=20 is outside the scope of the document and this information can be=20 provided
   by other means, such as email or the=20 Web.

9.      =20 In the = example in=20 section 11.1 the addConferenceAck message returns Conference ID: 000. = Shouldn=92t=20 it be the same as the ELEMENT-ID.

[ON] I just try to = keep the=20 same behaviour in the addConferenceAck message than in = the other=20 messages. Normally, when a server receives a CSCP or BFCP message, it = copies in=20 the response the same Conference-ID attribute than the one in the = message=20 receives.

10.  =20 I noticed = that=20 section 12 talks about correlation with the conference event package. = Just note=20 that the dial-out-list in the example of section 11.3 is not a child = element of=20 users. There is no dial-out list in the event package, since this is not = a=20 state. There is information inside the endpoint element if this was a = dial out=20 or dial in call.

[ON] The = dial-out-list is=20 defined in the "Common Conference Information Data Model for Centralized = Conferencing (XCON)" as an element of users. The dial-out-list is not = defined in=20 the event package because the event package only shows the state of the=20 conference.

Roni=20 Even
------_=_NextPart_001_01C62354.F890AC76-- --===============1775180714== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1775180714==-- From xcon-bounces@ietf.org Fri Jan 27 10:32:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VaL-0003VQ-UB; Fri, 27 Jan 2006 10:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VaK-0003V9-5N for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:32:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19341 for ; Fri, 27 Jan 2006 10:30:51 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VkU-0003EY-0J for xcon@ietf.org; Fri, 27 Jan 2006 10:42:55 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C99624F0001; Fri, 27 Jan 2006 16:32:20 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:32:20 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:32:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 16:32:18 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQALjYCw From: "Oscar Novo $JO/LMF$" To: "Chris Boulton" , X-OriginalArrivalTime: 27 Jan 2006 15:32:20.0174 (UTC) FILETIME=[DC97E6E0:01C62356] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.9 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2070908697==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2070908697== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62356.820C85FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62356.820C85FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Chris, =20 I think you are focusing too much in the web services. The protocol we choose has to have a good performance in a bunch of uses cases, not only web services (for instance: mobile phones, PDA, wireless, etc...) and I believe CSCP is much compact and it will have a better performance in wireless, and handset devices than SOAP.=20 And another thing that is quite important, CSCP can be uses in web services but, probably, SOAP will be a problem in some systems with low bandwidth. =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 12:01 To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. =20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 ------_=_NextPart_001_01C62356.820C85FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=20 Chris,

I=20 think you are focusing too much in the web services. The protocol we = choose has=20 to have a good performance in a bunch of uses cases, not only web = services (for=20 instance: mobile phones, PDA, wireless, etc...) and I believe CSCP = is much=20 compact and it will have a better performance in wireless, and handset = devices=20 than SOAP.

And=20 another thing that is quite important, CSCP can be uses in web services = but,=20 probably, SOAP will be a problem in some systems with low=20 bandwidth.

Oscar

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent:=20 27. tammikuuta 2006 12:01
To: xcon@ietf.org
Cc:=20 ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference=20 Control

Hi All,

Just wanted to generate = some=20 discussion relating to the recent Conference Control submissions. = I would=20 like to begin by thanking all the relevant parties for the effort = contributed=20 before Christmas.

While I realise that the = thoughts=20 conveyed in this mail are a little controversial, I thought I would poke = my head=20 up into the firing line in attempt to stimulate some discussion. I = have=20 reviewed all of the proposals and will be providing questions and = feedback in=20 individual mails. This mail is an attempt to discuss some = architectural=20 decisions that I personally feel are equally as important. As some = of you=20 may already know, I am a supporter of the SOAP proposals (Henning, = myself and=20 Mary) that are currently being worked on. This led me to realise = that my=20 preference was being swayed (purely selfish :-) by ‘who exactly = will be a=20 conference client manipulating Conference Objects?’ As an = application=20 server vendor who’s product very much utilises web services. SOAP = seems the=20 obvious choice. From a handset vendor I can also see that = proposals such=20 as CCCP and CSCP are more appealing. As an application server = offering=20 conferencing services using web services it may be likely, as it is not=20 mandatory, that BFCP be implemented in the solution and so developing = support=20 for something like CSCP would be seen as a burden, especially as we = already have=20 a web services interface that provides all the relevant infrastructure = to link=20 to our clients.

It is for these reasons = that I was=20 pondering the prospect of XCON allowing both a handset friendly = interface such=20 as CSCP and a SOAP interface for web services where the client might = well be=20 another application and not a handset. I realise that having two=20 interfaces is not ideal, but as long as we are careful in our rules on = minimal=20 implementation and ability to advertise capabilities to a Conference = Client I=20 personally feel that this is the best solution to make XCON appealing to = a wide=20 variety of architectures.

I’m going to duck = now and wait for=20 incoming bullets but on a serious note I strongly appeal to all who are=20 interested on making Dallas a=20 productive meeting to comment on mails such as this over the coming=20 months.

Best = Regards,

Chris = Boulton.

Information contained in this = e-mail and=20 any attachments are intended for the use of the addressee only, and may = contain=20 confidential information of Ubiquity Software Corporation. All = unauthorized use,=20 disclosure or distribution is strictly prohibited. If you are not = the=20 addressee, please notify the sender immediately and destroy all copies = of this=20 email. Unless otherwise expressly agreed in writing signed by an = officer=20 of Ubiquity Software Corporation, nothing in this communication shall be = deemed=20 to be legally binding. Thank-you ------_=_NextPart_001_01C62356.820C85FA-- --===============2070908697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============2070908697==-- From xcon-bounces@ietf.org Fri Jan 27 10:37:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VfQ-0000jS-IR; Fri, 27 Jan 2006 10:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VfO-0000eG-Mt for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19899 for ; Fri, 27 Jan 2006 10:36:05 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VpV-0003Tf-4z for xcon@ietf.org; Fri, 27 Jan 2006 10:48:10 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 951E64D7; Fri, 27 Jan 2006 16:37:25 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 16:37:25 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:37:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 16:37:23 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIA== From: "Oscar Novo $JO/LMF$" To: "Chris Boulton" , , X-OriginalArrivalTime: 27 Jan 2006 15:37:25.0444 (UTC) FILETIME=[928C6840:01C62357] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.7 (/) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664255086==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0664255086== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62357.374D8C16" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62357.374D8C16 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris, =20 Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory. So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch. =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. =20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 ------_=_NextPart_001_01C62357.374D8C16 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Chris,

Notice=20 that almost all the conference systems will implement the BFCP even=20 thought it is not compulsory. So, at the end few systems would have = to=20 develop the protocol from scratch but If SOAP is going to be the=20 protocol all the conference systems have to develop the = protocol from=20 scratch.

Oscar

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent:=20 27. tammikuuta 2006 17:13
To: br@brianrosen.net;=20 xcon@ietf.org
Cc: ajohnston@tello.com; Adam = Roach
Subject:=20 RE: [XCON] Conference Control

Hi=20 Brian,

Clarification = in-line.

Chris.

-----Original=20 Message-----
From: = Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: 27 January 2006 = 14:27
To: Chris Boulton;=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; 'Adam Roach'
Subject: RE: [XCON] Conference=20 Control

I’m not=20 opposed to having two bindings to the same interface, but I would not = want to=20 see two interfaces. That means the models, data structures, = operations,=20 errors, etc would have to be identical, with only transport being=20 different. I’m not sure that would be particularly = interesting to=20 you.

Also,=20 could you clarify your statements on CSCP? What you said was=20 “it may be likely, as it is = not=20 mandatory, that BFCP be implemented in the solution and so developing = support=20 for something like CSCP would be seen as a burden”. I = can’t figure out if=20 you WILL implement BFCP, and thus CSCP is easy, or you won’t = implement BFCP=20 because it’s not mandatory and thus CSCP would be a burden. = I think if you=20 implement BFCP then CSCP is relatively less work from there. =

[Chris=20 Boulton] The XCON Framework reads:
Floor = control is not a mandatory mechanism for a conferencing system = implementation but provides advanced media input control features for = conference users.

So=20 the point I was trying to convey was that BFCP, as it stands in the = Framework is=20 not mandatory. So for an element wanting to use just CSCP would = have to=20 develop from scratch. In this scenario, just having to expose a = WSDL=20 initiated web interface is preferred.

Chris.

Brian

From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent: Friday, January 27, 2006 = 5:01=20 AM
To:=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference=20 Control

Hi = All,

Just wanted = to generate=20 some discussion relating to the recent Conference Control = submissions. I=20 would like to begin by thanking all the relevant parties for the effort=20 contributed before Christmas.

While I = realise that the=20 thoughts conveyed in this mail are a little controversial, I thought I = would=20 poke my head up into the firing line in attempt to stimulate some=20 discussion. I have reviewed all of the proposals and will be = providing=20 questions and feedback in individual mails. This mail is an = attempt to=20 discuss some architectural decisions that I personally feel are equally = as=20 important. As some of you may already know, I am a supporter of = the SOAP=20 proposals (Henning, myself and Mary) that are currently being worked = on. =20 This led me to realise that my preference was being swayed (purely = selfish :-)=20 by ‘who exactly will be a conference client manipulating = Conference=20 Objects?’ As an application server vendor who’s = product very much utilises=20 web services. SOAP seems the obvious choice. From a handset vendor = I can=20 also see that proposals such as CCCP and CSCP are more appealing. = As an=20 application server offering conferencing services using web services it = may be=20 likely, as it is not mandatory, that BFCP be implemented in the solution = and so=20 developing support for something like CSCP would be seen as a burden, = especially=20 as we already have a web services interface that provides all the = relevant=20 infrastructure to link to our clients.

It is for = these reasons=20 that I was pondering the prospect of XCON allowing both a handset = friendly=20 interface such as CSCP and a SOAP interface for web services where the = client=20 might well be another application and not a handset. I realise = that having=20 two interfaces is not ideal, but as long as we are careful in our rules = on=20 minimal implementation and ability to advertise capabilities to a = Conference=20 Client I personally feel that this is the best solution to make XCON = appealing=20 to a wide variety of architectures.

I’m = going to duck now and=20 wait for incoming bullets but on a serious note I strongly appeal to all = who are=20 interested on making Dallas a productive meeting to comment on mails = such as=20 this over the coming months.

Best=20 Regards,

Chris=20 Boulton.

Information contained = in this=20 e-mail and any attachments are intended for the use of the addressee = only, and=20 may contain confidential information of Ubiquity Software Corporation. = All=20 unauthorized use, disclosure or distribution is strictly = prohibited. If=20 you are not the addressee, please notify the sender immediately and = destroy all=20 copies of this email. Unless otherwise expressly agreed in writing = signed=20 by an officer of Ubiquity Software Corporation, nothing in this = communication=20 shall be deemed to be legally binding. Thank-you=20
------_=_NextPart_001_01C62357.374D8C16-- --===============0664255086== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0664255086==-- From xcon-bounces@ietf.org Fri Jan 27 10:42:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VkP-0004Km-U8; Fri, 27 Jan 2006 10:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VkO-0004Kc-6C for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:42:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20255 for ; Fri, 27 Jan 2006 10:41:15 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VuY-0003f3-QC for xcon@ietf.org; Fri, 27 Jan 2006 10:53:20 -0500 Received: from rly07b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly07b.srv.mailcontrol.com (MailControl) with ESMTP id k0RFgYQw004201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 15:42:34 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly07b.srv.mailcontrol.com (MailControl) id k0RFgX1o004182 for xcon@ietf.org; Fri, 27 Jan 2006 15:42:33 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly07b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0RFgVx4004100; Fri, 27 Jan 2006 15:42:33 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 15:42:30 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78A96@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tA From: "Chris Boulton" To: "Oscar Novo $JO/LMF$" , , X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.117 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8d895f7c89fea7fff87709b22b67e77e Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242252962==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1242252962== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62358.48A3BB30" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62358.48A3BB30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch. =20 Oscar _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.=20=20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C62358.48A3BB30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Chris,

= Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this comments based on?

= So, at the end few systems would have to develop the protocol from scratch but&nbs= p;If SOAP is going to be the protocol all the conference systems have = to develop the protocol from scratch.

= Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behal= f Of Chris Boulton
Sent: 27. tammikuuta 2006 17:13=
To: br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conferen= ce Control

= Hi Brian,

= Clarification in-line.

= Chris.

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: 27= January 2006= 14:27=
To: Chris Boulton; xcon@ietf= .org
Cc: ajohnston@tello.com; 'Ad= am Roach'
Subject: RE: [XCON] Conferen= ce Control

= I’m not opposed to having two bindings to the same interface, but I would not w= ant to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport bei= ng different. I’m not sure that would be particularly interesting = to you.

= Also, could you clarify your statements on CSCP? What you said was “<= /span>it may be likely, as it is not mandatory, that BFCP be implemented in the solu= tion and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement BFCP, a= nd thus CSCP is easy, or you won’t implement BFCP because it’s not mandatory and thus CSCP would be a burden. I think if you implement B= FCP then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework read= s:

Floor control is not a mandatory mechanism for a= conferencing system implementation but provides advanced media input contr= ol features for conference users.

So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. = In this scenario, just having to expose a WSDL initiated web interface is preferred.

Chris.

= Brian

From:= xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Fr= iday, January 27, 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference C= ontrol

Hi All,

Just wanted to ge= nerate some discussion relating to the recent Conference Control submissions. = ; I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I realise t= hat the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the S= OAP proposals (Henning, myself and Mary) that are currently being worked on.&nb= sp; This led me to realise that my preference was being swayed (purely selfish = :-) by ‘who exactly will be a conference client manipulating Conference Objects?’ As an application server vendor who’s product v= ery much utilises web services. SOAP seems the obvious choice. From a han= dset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services us= ing web services it may be likely, as it is not mandatory, that BFCP be impleme= nted in the solution and so developing support for something like CSCP would be = seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these r= easons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the clie= nt might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our ru= les on minimal implementation and ability to advertise capabilities to a Confer= ence Client I personally feel that this is the best solution to make XCON appeal= ing to a wide variety of architectures.

I’m going t= o duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making = Dallas a productive meeting to comment on mails such as this over the coming month= s.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, = and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. = If you are not the addressee, please notify the sender immediately and destroy= all copies of this email. Unless otherwise expressly agreed in writing si= gned by an officer of Ubiquity Software Corporation, nothing in this communicati= on shall be deemed to be legally binding. Thank-you

------_=_NextPart_001_01C62358.48A3BB30-- --===============1242252962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1242252962==-- From xcon-bounces@ietf.org Fri Jan 27 10:48:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vq9-0007cY-A5; Fri, 27 Jan 2006 10:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vq7-0007cT-Tz for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20828 for ; Fri, 27 Jan 2006 10:47:10 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2W0H-0003ua-Ho for xcon@ietf.org; Fri, 27 Jan 2006 10:59:15 -0500 Received: from rly21b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly21b.srv.mailcontrol.com (MailControl) with ESMTP id k0RFmTfa017110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 15:48:29 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly21b.srv.mailcontrol.com (MailControl) id k0RFlv4E016004 for xcon@ietf.org; Fri, 27 Jan 2006 15:47:57 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly21b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0RFlthe015913; Fri, 27 Jan 2006 15:47:57 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 15:47:54 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118907@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQALjYCwAABddRA= From: "Chris Boulton" To: "Oscar Novo $JO/LMF$" , X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.131 X-Spam-Score: 0.6 (/) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1044407898==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1044407898== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62359.09BF30D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62359.09BF30D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Hello Chris, =20 I think you are focusing too much in the web services. =20 [Chris Boulton] That was my realization and why I am trying to broaden my thinking rather than focusing on specific deployment restrictions. =20 The protocol we choose has to have a good performance in a bunch of uses cases, not only web services (for instance: mobile phones, PDA, wireless, etc...) and I believe CSCP is much compact and it will have a better performance in wireless, and handset devices than SOAP. =20 [Chris Boulton] See first comment :-). If you read my mail I am actually trying to discuss a potential solution that covers a complete set of architectures. Also this was not supposed to be a 'vs' debate. It was meant to probe the potential for supplying both. =20 And another thing that is quite important, CSCP can be uses in web services but, probably, SOAP will be a problem in some systems with low bandwidth. =20 [Chris Boulton] I get the handset bandwidth - I have heard it in almost every IETF meeting I've been to + I also agree it's a major consideration BUT lets not just keep harping back to it. =20 Oscar =20 _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 12:01 To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.=20=20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C62359.09BF30D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hello Chris,

= I think you are focusing too much in the web services.

[Chris Boulton] That was my realization and why I am try= ing to broaden my thinking rather than focusing on specific deployment restrictions.

= The protocol we choose has to have a good performance in a bunch of uses cases,= not only web services (for instance: mobile phones, PDA, wireless, etc...) and I believe CSCP is much compact and it will have a better performance in wireless, and handset devices than SOAP.

[Chris Boulton] See first comment = J. If you read my mail = I am actually trying to discuss a potential solution that covers a complete set = of architectures. Also this was not supposed to be a ‘vs’ debate. It was meant to probe the potential for supplying both.

=

= And another thing that is quite important, CSCP can be uses in web services but, probably, SOAP will be a problem in some systems with low bandwidth.=

[Chris Boulton] I get the handset bandwidth – I ha= ve heard it in almost every IETF meeting I’ve been to + I also agree it&= #8217;s a major consideration BUT lets not just keep harping back to it.

= Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behal= f Of Chris Boulton
Sent: 27. tammikuuta 2006 12:01=
To: xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference C= ontrol

Hi All,

Just wanted to ge= nerate some discussion relating to the recent Conference Control submissions. = ; I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I realise t= hat the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the S= OAP proposals (Henning, myself and Mary) that are currently being worked on.&nb= sp; This led me to realise that my preference was being swayed (purely selfish = :-) by ‘who exactly will be a conference client manipulating Conference Objects?’ As an application server vendor who’s product v= ery much utilises web services. SOAP seems the obvious choice. From a han= dset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services us= ing web services it may be likely, as it is not mandatory, that BFCP be impleme= nted in the solution and so developing support for something like CSCP would be = seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these r= easons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the clie= nt might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our ru= les on minimal implementation and ability to advertise capabilities to a Confer= ence Client I personally feel that this is the best solution to make XCON appeal= ing to a wide variety of architectures.

I’m going t= o duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making = Dallas a productive meeting to comment on mails such as this over the coming month= s.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, = and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. = If you are not the addressee, please notify the sender immediately and destroy= all copies of this email. Unless otherwise expressly agreed in writing si= gned by an officer of Ubiquity Software Corporation, nothing in this communicati= on shall be deemed to be legally binding. Thank-you

------_=_NextPart_001_01C62359.09BF30D8-- --===============1044407898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1044407898==-- From xcon-bounces@ietf.org Fri Jan 27 10:51:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vsm-0008BZ-7C; Fri, 27 Jan 2006 10:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vsj-0008BK-SG for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:51:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20959 for ; Fri, 27 Jan 2006 10:49:52 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2W2t-0003zC-GF for xcon@ietf.org; Fri, 27 Jan 2006 11:01:57 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 636E34F0002; Fri, 27 Jan 2006 16:50:38 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:50:37 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:50:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 16:50:36 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAAAhNRA= From: "Oscar Novo $JO/LMF$" To: "Chris Boulton" , , X-OriginalArrivalTime: 27 Jan 2006 15:50:37.0763 (UTC) FILETIME=[6ACEB130:01C62359] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.4 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0249858494==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0249858494== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62359.1003AA58" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62359.1003AA58 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it=B4s quite obvious. :)=20 But anyway, still all the systems have to implement the SOAP protocol = from the scratch and this is not the case of CSCP even if the systems = that support the BFCP are low.=20 =20 Don=B4t be mad at me. :) =20 ________________________________ From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: 27. tammikuuta 2006 17:43 To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP = even thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from = scratch but If SOAP is going to be the protocol all the conference = systems have to develop the protocol from scratch. =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I = would not want to see two interfaces. That means the models, data = structures, operations, errors, etc would have to be identical, with = only transport being different. I'm not sure that would be particularly = interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it = may be likely, as it is not mandatory, that BFCP be implemented in the = solution and so developing support for something like CSCP would be seen = as a burden". I can't figure out if you WILL implement BFCP, and thus = CSCP is easy, or you won't implement BFCP because it's not mandatory and = thus CSCP would be a burden. I think if you implement BFCP then CSCP is = relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system = implementation but provides advanced media input control features for = conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the = Framework is not mandatory. So for an element wanting to use just CSCP = would have to develop from scratch. In this scenario, just having to = expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent = Conference Control submissions. I would like to begin by thanking all = the relevant parties for the effort contributed before Christmas. =20 =20 While I realise that the thoughts conveyed in this mail are a little = controversial, I thought I would poke my head up into the firing line in = attempt to stimulate some discussion. I have reviewed all of the = proposals and will be providing questions and feedback in individual = mails. This mail is an attempt to discuss some architectural decisions = that I personally feel are equally as important. As some of you may = already know, I am a supporter of the SOAP proposals (Henning, myself = and Mary) that are currently being worked on. This led me to realise = that my preference was being swayed (purely selfish :-) by 'who exactly = will be a conference client manipulating Conference Objects?' As an = application server vendor who's product very much utilises web services. = SOAP seems the obvious choice. From a handset vendor I can also see = that proposals such as CCCP and CSCP are more appealing. As an = application server offering conferencing services using web services it = may be likely, as it is not mandatory, that BFCP be implemented in the = solution and so developing support for something like CSCP would be seen = as a burden, especially as we already have a web services interface that = provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON = allowing both a handset friendly interface such as CSCP and a SOAP = interface for web services where the client might well be another = application and not a handset. I realise that having two interfaces is = not ideal, but as long as we are careful in our rules on minimal = implementation and ability to advertise capabilities to a Conference = Client I personally feel that this is the best solution to make XCON = appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious = note I strongly appeal to all who are interested on making Dallas a = productive meeting to comment on mails such as this over the coming = months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended = for the use of the addressee only, and may contain confidential = information of Ubiquity Software Corporation. All unauthorized use, = disclosure or distribution is strictly prohibited. If you are not the = addressee, please notify the sender immediately and destroy all copies = of this email. Unless otherwise expressly agreed in writing signed by = an officer of Ubiquity Software Corporation, nothing in this = communication shall be deemed to be legally binding. Thank-you=20 ------_=_NextPart_001_01C62359.1003AA58 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I = think it=B4s=20 quite obvious. :)

But anyway, still all the systems have to = implement the=20 SOAP protocol from the scratch and this is not the case of CSCP = even if=20 the systems that support the BFCP are = low.

Don=B4t=20 be mad at me. :)

From: Chris Boulton=20 [mailto:cboulton@ubiquity.net]
Sent: 27. tammikuuta 2006=20 17:43
To: Oscar Novo (JO/LMF); br@brianrosen.net;=20 xcon@ietf.org
Cc: ajohnston@tello.com; Adam = Roach
Subject:=20 RE: [XCON] Conference Control

Chris,

Notice=20 that almost all the conference systems will implement the BFCP even=20 thought it is not compulsory.

[Chris=20 Boulton] What proof is this comments based on?

So,=20 at the end few systems would have to develop the protocol from scratch=20 but If SOAP is going to be the protocol all the conference=20 systems have to develop the protocol from = scratch.

Oscar

From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent: 27. tammikuuta 2006=20 17:13
To: br@brianrosen.net;=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conference=20 Control

Hi=20 Brian,

Clarification = in-line.

Chris.

-----Original=20 Message-----
From: = Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: 27 January = 2006 14:27
To: Chris Boulton;=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; 'Adam Roach'
Subject: RE: [XCON] Conference=20 Control

I=92m not=20 opposed to having two bindings to the same interface, but I would not = want to=20 see two interfaces. That means the models, data structures, = operations,=20 errors, etc would have to be identical, with only transport being=20 different. I=92m not sure that would be particularly interesting = to=20 you.

Also,=20 could you clarify your statements on CSCP? What you said was=20 =93it may be likely, as it is = not=20 mandatory, that BFCP be implemented in the solution and so developing = support=20 for something like CSCP would be seen as a burden=94. I can=92t = figure out if=20 you WILL implement BFCP, and thus CSCP is easy, or you won=92t implement = BFCP=20 because it=92s not mandatory and thus CSCP would be a burden. I = think if you=20 implement BFCP then CSCP is relatively less work from there. =

[Chris=20 Boulton] The XCON Framework reads:
Floor control is not a mandatory mechanism for = a conferencing system implementation but provides advanced media input = control features for conference users.

So=20 the point I was trying to convey was that BFCP, as it stands in the = Framework is=20 not mandatory. So for an element wanting to use just CSCP would = have to=20 develop from scratch. In this scenario, just having to expose a = WSDL=20 initiated web interface is preferred.

Chris.

Brian

From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent: Friday, = January 27,=20 2006 5:01=20 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; Adam=20 Roach
Subject: [XCON] = Conference Control

Hi = All,

Just wanted = to generate=20 some discussion relating to the recent Conference Control = submissions. I=20 would like to begin by thanking all the relevant parties for the effort=20 contributed before Christmas.

While I = realise that the=20 thoughts conveyed in this mail are a little controversial, I thought I = would=20 poke my head up into the firing line in attempt to stimulate some=20 discussion. I have reviewed all of the proposals and will be = providing=20 questions and feedback in individual mails. This mail is an = attempt to=20 discuss some architectural decisions that I personally feel are equally = as=20 important. As some of you may already know, I am a supporter of = the SOAP=20 proposals (Henning, myself and Mary) that are currently being worked = on. =20 This led me to realise that my preference was being swayed (purely = selfish :-)=20 by =91who exactly will be a conference client manipulating Conference=20 Objects?=92 As an application server vendor who=92s product very = much utilises=20 web services. SOAP seems the obvious choice. From a handset vendor = I can=20 also see that proposals such as CCCP and CSCP are more appealing. = As an=20 application server offering conferencing services using web services it = may be=20 likely, as it is not mandatory, that BFCP be implemented in the solution = and so=20 developing support for something like CSCP would be seen as a burden, = especially=20 as we already have a web services interface that provides all the = relevant=20 infrastructure to link to our clients.

It is for = these reasons=20 that I was pondering the prospect of XCON allowing both a handset = friendly=20 interface such as CSCP and a SOAP interface for web services where the = client=20 might well be another application and not a handset. I realise = that having=20 two interfaces is not ideal, but as long as we are careful in our rules = on=20 minimal implementation and ability to advertise capabilities to a = Conference=20 Client I personally feel that this is the best solution to make XCON = appealing=20 to a wide variety of architectures.

I=92m going = to duck now and=20 wait for incoming bullets but on a serious note I strongly appeal to all = who are=20 interested on making Dallas a=20 productive meeting to comment on mails such as this over the coming=20 months.

Best=20 Regards,

Chris=20 Boulton.

Information contained = in this=20 e-mail and any attachments are intended for the use of the addressee = only, and=20 may contain confidential information of Ubiquity Software Corporation. = All=20 unauthorized use, disclosure or distribution is strictly = prohibited. If=20 you are not the addressee, please notify the sender immediately and = destroy all=20 copies of this email. Unless otherwise expressly agreed in writing = signed=20 by an officer of Ubiquity Software Corporation, nothing in this = communication=20 shall be deemed to be legally binding. Thank-you=20
------_=_NextPart_001_01C62359.1003AA58-- --===============0249858494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0249858494==-- From xcon-bounces@ietf.org Fri Jan 27 10:52:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vtj-0008Mc-4T; Fri, 27 Jan 2006 10:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vth-0008MU-M0 for xcon@megatron.ietf.org; Fri, 27 Jan 2006 10:52:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21016 for ; Fri, 27 Jan 2006 10:50:52 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2W3s-00040q-Ed for xcon@ietf.org; Fri, 27 Jan 2006 11:02:57 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F2VtU-0001AD-Lx; Fri, 27 Jan 2006 09:52:16 -0600 From: "Brian Rosen" To: "'Chris Boulton'" , "'Oscar Novo $JO/LMF$'" , Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 10:50:11 -0500 Message-ID: <02ea01c62359$5e5ea400$651f0a0a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAAAv9IA= In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78A96@gbnewp0758m.eu.ubiquity.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.3 (/) X-Scan-Signature: b92e72fc2b623ddd11e6d81413fb81b2 Cc: ajohnston@tello.com, 'Adam Roach' X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1764080436==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1764080436== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EB_01C6232F.75889C00" This is a multi-part message in MIME format. ------=_NextPart_000_02EB_01C6232F.75889C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I guess that this is whether floor control is seen as a "must have" feature in a conference client. Basically, I think that if you need any more than the basic conference control that comes with nothing more than the conference package and other SIP mechanisms; that is, you implement the conference control package, you have a rich enough client that floor control would be essential. I'd be hard pressed to think of a client that would have the conference control package without floor control. It's POSSIBLE, but I don't think its probable. Floor control is kind of a fundamental thing beyond the simplistic kinds of conferences that don't need any of the xcon stuff. Brian _____ From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: Friday, January 27, 2006 10:42 AM To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Chris, Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory. [Chris Boulton] What proof is this comments based on? So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch. Oscar _____ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, Clarification in-line. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there. [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred. Chris. Brian _____ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control Hi All, Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. Best Regards, Chris Boulton. Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you ------=_NextPart_000_02EB_01C6232F.75889C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess that this is whether floor = control is seen as a “must have” feature in a conference = client.

Basically, I think that if you need = any more than the basic conference control that comes with nothing more than = the conference package and other SIP mechanisms; that is, you implement the conference control package, you have a rich enough client that floor = control would be essential. I’d be hard pressed to think of a client = that would have the conference control package without floor control. = It’s POSSIBLE, but I don’t think its probable. Floor control is = kind of a fundamental thing beyond the simplistic kinds of conferences that = don’t need any of the xcon stuff.

Brian

From: Chris = Boulton [mailto:cboulton@ubiquity.net]
Sent: Friday, January 27, = 2006 10:42 AM
To: Oscar Novo (JO/LMF); = br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

Chris,

Notice that = almost all the conference systems will implement the BFCP even thought it is = not compulsory.

[Chris Boulton] What proof is this comments based = on?

So, at the = end few systems would have to develop the protocol from scratch but If SOAP = is going to be the protocol all the conference systems have to = develop the protocol from scratch.

Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: 27. tammikuuta 2006 = 17:13
To: br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

Hi = Brian,

Clarification = in-line.

Chris.

-----Original = Message-----
From: Brian Rosen = [mailto:br@brianrosen.net]
Sent: 27 January 2006 = 14:27
To: Chris Boulton; = xcon@ietf.org
Cc: ajohnston@tello.com; = 'Adam Roach'
Subject: RE: [XCON] = Conference Control

I’m not opposed to having two bindings to the same interface, but I would = not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport = being different. I’m not sure that would be particularly = interesting to you.

Also, could you clarify your statements on CSCP? What you said was = “it may be likely, as it is not mandatory, that BFCP be implemented in the = solution and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement = BFCP, and thus CSCP is easy, or you won’t implement BFCP because it’s = not mandatory and thus CSCP would be a burden. I think if you implement BFCP = then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework = reads:

Floor control is not a mandatory mechanism = for a conferencing system implementation but provides advanced media = input control features for conference = users.

So the point I was trying to convey = was that BFCP, as it stands in the Framework is not mandatory. So for = an element wanting to use just CSCP would have to develop from = scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred.

Chris.

Brian

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Friday, January 27, = 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: [XCON] = Conference Control

Hi = All,

Just wanted to = generate some discussion relating to the recent Conference Control = submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I = realise that the thoughts conveyed in this mail are a little controversial, I thought I = would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be = providing questions and feedback in individual mails. This mail is an = attempt to discuss some architectural decisions that I personally feel are equally = as important. As some of you may already know, I am a supporter of = the SOAP proposals (Henning, myself and Mary) that are currently being worked = on. This led me to realise that my preference was being swayed (purely = selfish :-) by ‘who exactly will be a conference client manipulating = Conference Objects?’ As an application server vendor who’s = product very much utilises web services. SOAP seems the obvious choice. From a = handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services = using web services it may be likely, as it is not mandatory, that BFCP be = implemented in the solution and so developing support for something like CSCP would = be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our = clients.

It is for = these reasons that I was pondering the prospect of XCON allowing both a handset = friendly interface such as CSCP and a SOAP interface for web services where the = client might well be another application and not a handset. I realise = that having two interfaces is not ideal, but as long as we are careful in our = rules on minimal implementation and ability to advertise capabilities to a = Conference Client I personally feel that this is the best solution to make XCON = appealing to a wide variety of architectures.

I’m = going to duck now and wait for incoming bullets but on a serious note I strongly = appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming = months.

Best = Regards,

Chris = Boulton.

Information contained in = this e-mail and any attachments are intended for the use of the addressee = only, and may contain confidential information of Ubiquity Software Corporation. = All unauthorized use, disclosure or distribution is strictly = prohibited. If you are not the addressee, please notify the sender immediately and = destroy all copies of this email. Unless otherwise expressly agreed in writing = signed by an officer of Ubiquity Software Corporation, nothing in this = communication shall be deemed to be legally binding. Thank-you =

------=_NextPart_000_02EB_01C6232F.75889C00-- --===============1764080436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1764080436==-- From xcon-bounces@ietf.org Fri Jan 27 11:00:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W1B-00041b-RU; Fri, 27 Jan 2006 11:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W19-00041N-R2 for xcon@megatron.ietf.org; Fri, 27 Jan 2006 11:00:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21718 for ; Fri, 27 Jan 2006 10:58:34 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WBK-0004Ix-Ch for xcon@ietf.org; Fri, 27 Jan 2006 11:10:39 -0500 Received: from rly03b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly03b.srv.mailcontrol.com (MailControl) with ESMTP id k0RFxp0F008505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 15:59:56 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly03b.srv.mailcontrol.com (MailControl) id k0RFxYH4006291 for xcon@ietf.org; Fri, 27 Jan 2006 15:59:34 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly03b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0RFxWn0006130; Fri, 27 Jan 2006 15:59:34 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 15:59:32 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118908@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAAAhNRAAAFaOQA== From: "Chris Boulton" To: "Oscar Novo $JO/LMF$" , , X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.113 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a25a3f15cd7c4f2ea7dd14d5f6b4bd1 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0840784181==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0840784181== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6235A.A98EF498" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6235A.A98EF498 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 I think it=B4s quite obvious. :)=20 But anyway, still all the systems have to implement the SOAP protocol from= the scratch and this is not the case of CSCP even if the systems that supp= ort the BFCP are low.=20 =20 Don=B4t be mad at me. :) =20 [Chris Boulton] hehehe - how could I. This isn't a 'vs' debate - I'm just = saying that if you have got a web services SOAP interface, it would be usef= ul for XCON to provide hooks so that clients (e.g. J2EE applications not UA= 's or handsets) can control conferences using mechanisms that they find com= mon e.g. SOAP, WSDL, UDDI. I agree that this Conference System would almos= t certainly have a BFCP interface (and therefore a CSCP interface), but my = client application would probably not.=20 =20 =20 _____=20=20 From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: 27. tammikuuta 2006 17:43 To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP even = thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from scratch= but If SOAP is going to be the protocol all the conference systems have to= develop the protocol from scratch. =20 Oscar _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chr= is Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would n= ot want to see two interfaces. That means the models, data structures, ope= rations, errors, etc would have to be identical, with only transport being = different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may= be likely, as it is not mandatory, that BFCP be implemented in the solutio= n and so developing support for something like CSCP would be seen as a burd= en". I can't figure out if you WILL implement BFCP, and thus CSCP is easy,= or you won't implement BFCP because it's not mandatory and thus CSCP would= be a burden. I think if you implement BFCP then CSCP is relatively less w= ork from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implem= entation but provides advanced media input control features for conference = users. =20 So the point I was trying to convey was that BFCP, as it stands in the Fram= ework is not mandatory. So for an element wanting to use just CSCP would h= ave to develop from scratch. In this scenario, just having to expose a WSD= L initiated web interface is preferred. Chris. =20 =20 Brian =20 _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chr= is Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference C= ontrol submissions. I would like to begin by thanking all the relevant par= ties for the effort contributed before Christmas.=20=20 =20 While I realise that the thoughts conveyed in this mail are a little contro= versial, I thought I would poke my head up into the firing line in attempt = to stimulate some discussion. I have reviewed all of the proposals and wil= l be providing questions and feedback in individual mails. This mail is an= attempt to discuss some architectural decisions that I personally feel are= equally as important. As some of you may already know, I am a supporter o= f the SOAP proposals (Henning, myself and Mary) that are currently being wo= rked on. This led me to realise that my preference was being swayed (purel= y selfish :-) by 'who exactly will be a conference client manipulating Conf= erence Objects?' As an application server vendor who's product very much u= tilises web services. SOAP seems the obvious choice. From a handset vendor= I can also see that proposals such as CCCP and CSCP are more appealing. A= s an application server offering conferencing services using web services i= t may be likely, as it is not mandatory, that BFCP be implemented in the so= lution and so developing support for something like CSCP would be seen as a= burden, especially as we already have a web services interface that provid= es all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing = both a handset friendly interface such as CSCP and a SOAP interface for web= services where the client might well be another application and not a hand= set. I realise that having two interfaces is not ideal, but as long as we = are careful in our rules on minimal implementation and ability to advertise= capabilities to a Conference Client I personally feel that this is the bes= t solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I= strongly appeal to all who are interested on making Dallas a productive me= eting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribut= ion is strictly prohibited. If you are not the addressee, please notify th= e sender immediately and destroy all copies of this email. Unless otherwis= e expressly agreed in writing signed by an officer of Ubiquity Software Cor= poration, nothing in this communication shall be deemed to be legally bindi= ng. Thank-you=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C6235A.A98EF498 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= I think it=B4s quite obvious. :)

= But anyway, still all the systems have to implement the SOAP protocol from the scratch and this is not the case of CSCP even if the systems that suppo= rt the BFCP are low.

= Don=B4t be mad at me. :)

=

[Chris Boulton] hehehe – how could I. =A0This isn&= #8217;t a ‘vs’ debate – I’m just saying that if you have go= t a web services SOAP interface, it would be useful for XCON to provide hooks so that clients (e.g. J2EE applications not UA’s or handsets) can control conferences using mechanisms that they find common e.g. SOAP, WSDL, UDDI.= =A0 I agree that this Conference System would almost certainly have a BFCP interf= ace (and therefore a CSCP interface), but my client application would probably = not.

From: Chris Boulton [mailto:cboulton@ubiquity.net]
Sent: 27. tammikuuta 2006 17:43=
To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conferen= ce Control

= Chris,

= Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this comm= ents based on?

= So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch.

= Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behal= f Of Chris Boulton
Sent: 27. tammikuuta 2006 17:13=
To: br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conferen= ce Control

= Hi Brian,

= Clarification in-line.

= Chris.

-----Original Message-----
From: Brian Rosen [mailto:br= @brianrosen.net]
Sent: 27= January 2006= 14:27=
To: Chris Boulton; xcon@ietf= .org
Cc: ajohnston@tello.com; 'Ad= am Roach'
Subject: RE: [XCON] Conferen= ce Control

= I’m not opposed to having two bindings to the same interface, but I would not w= ant to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport bei= ng different. I’m not sure that would be particularly interesting = to you.

= Also, could you clarify your statements on CSCP? What you said was “<= /span>it may be likely, as it is not mandatory, that BFCP be implemented in the solu= tion and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement BFCP, a= nd thus CSCP is easy, or you won’t implement BFCP because it’s not mandatory and thus CSCP would be a burden. I think if you implement B= FCP then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework read= s:

Floor control is not a mandatory mechanism for a= conferencing system implementation but provides advanced media input contr= ol features for conference users.

So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. = In this scenario, just having to expose a WSDL initiated web interface is preferred.

Chris.

= Brian

From:= xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Fr= iday, January 27, 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference C= ontrol

Hi All,

Just wanted to ge= nerate some discussion relating to the recent Conference Control submissions. = ; I would like to begin by thanking all the relevant parties for the effort contribut= ed before Christmas.

While I realise t= hat the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the S= OAP proposals (Henning, myself and Mary) that are currently being worked on.&nb= sp; This led me to realise that my preference was being swayed (purely selfish = :-) by ‘who exactly will be a conference client manipulating Conference Objects?’ As an application server vendor who’s product v= ery much utilises web services. SOAP seems the obvious choice. From a han= dset vendor I can also see that proposals such as CCCP and CSCP are more appeali= ng. As an application server offering conferencing services using web services = it may be likely, as it is not mandatory, that BFCP be implemented in the solu= tion and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these r= easons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the clie= nt might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our ru= les on minimal implementation and ability to advertise capabilities to a Confer= ence Client I personally feel that this is the best solution to make XCON appeal= ing to a wide variety of architectures.

I’m going t= o duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making = Dallas a productive meeting to comment on mails such as this over the coming month= s.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, = and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. = If you are not the addressee, please notify the sender immediately and destroy= all copies of this email. Unless otherwise expressly agreed in writing si= gned by an officer of Ubiquity Software Corporation, nothing in this communicati= on shall be deemed to be legally binding. Thank-you

------_=_NextPart_001_01C6235A.A98EF498-- --===============0840784181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0840784181==-- From xcon-bounces@ietf.org Fri Jan 27 11:03:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W4a-0004g2-G8; Fri, 27 Jan 2006 11:03:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W4Z-0004fu-Iq for xcon@megatron.ietf.org; Fri, 27 Jan 2006 11:03:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21968 for ; Fri, 27 Jan 2006 11:02:06 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WEk-0004QT-54 for xcon@ietf.org; Fri, 27 Jan 2006 11:14:11 -0500 Received: from lion.cs.columbia.edu (IDENT:sDMIH0czm683NrXR39jB4o/wlsvNQndo@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0RFxtKG014668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 27 Jan 2006 11:03:30 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0RFxrnE017502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jan 2006 10:59:54 -0500 Message-ID: <43DA4377.5020900@cs.columbia.edu> Date: Fri, 27 Jan 2006 10:59:51 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chris Boulton Subject: Re: [XCON] Conference Control References: <45730E094814E44488F789C1CDED27AE03118907@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE03118907@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id k0RFxtKG014668 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , ajohnston@tello.com, xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org > */[Chris Boulton] I get the handset bandwidth =96 I have heard it in=20 > almost every IETF meeting I=92ve been to + I also agree it=92s a major=20 > consideration BUT lets not just keep harping back to it./* >=20 This is largely a bogus argument. In any multimedia conference, the=20 control bandwidth is going to be a tiny fraction of the overall=20 bandwidth consumed by media. It is even less likely to be a factor since=20 a large part of data in conference control is likely to be text in any=20 protocol, such as URI's, conference descriptions, or names. Let's not trot out the same non-relevant arguments each time. Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 27 11:04:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W53-0004mV-4r; Fri, 27 Jan 2006 11:04:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2W51-0004lT-Eh for xcon@megatron.ietf.org; Fri, 27 Jan 2006 11:04:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21983 for ; Fri, 27 Jan 2006 11:02:34 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WFC-0004Qt-0t for xcon@ietf.org; Fri, 27 Jan 2006 11:14:39 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F2W4r-00036n-6c; Fri, 27 Jan 2006 10:04:00 -0600 From: "Brian Rosen" To: "'Chris Boulton'" , "'Oscar Novo $JO/LMF$'" , Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 11:01:57 -0500 Message-ID: <030301c6235b$05766880$651f0a0a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAAAhNRAAAFaOQAAAMuRA In-Reply-To: <45730E094814E44488F789C1CDED27AE03118908@gbnewp0758m.eu.ubiquity.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.3 (/) X-Scan-Signature: fedb3c53163e7310de985aa5c1c03936 Cc: ajohnston@tello.com, 'Adam Roach' X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0062374533==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0062374533== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0304_01C62331.1CA06080" This is a multi-part message in MIME format. ------=_NextPart_000_0304_01C62331.1CA06080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Okay, so, we could talk about two bindings for one data = model/interaction model if we wanted to. =20 =20 An interesting question follows from that: would you want a SOAP based binding for floor control? =20 Brian =20 _____ =20 From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Friday, January 27, 2006 11:00 AM To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 =20 I think it=B4s quite obvious. :)=20 But anyway, still all the systems have to implement the SOAP protocol = from the scratch and this is not the case of CSCP even if the systems that support the BFCP are low.=20 =20 Don=B4t be mad at me. :) =20 [Chris Boulton] hehehe =96 how could I. This isn=92t a =91vs=92 debate = =96 I=92m just saying that if you have got a web services SOAP interface, it would be useful for XCON to provide hooks so that clients (e.g. J2EE applications = not UA=92s or handsets) can control conferences using mechanisms that they = find common e.g. SOAP, WSDL, UDDI. I agree that this Conference System would almost certainly have a BFCP interface (and therefore a CSCP interface), = but my client application would probably not.=20 =20 =20 _____ =20 From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: 27. tammikuuta 2006 17:43 To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP = even thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from = scratch but If SOAP is going to be the protocol all the conference systems have = to develop the protocol from scratch. =20 Oscar _____ =20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I=92m not opposed to having two bindings to the same interface, but I = would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I=92m not sure that would be particularly interesting = to you. =20 Also, could you clarify your statements on CSCP? What you said was = =93it may be likely, as it is not mandatory, that BFCP be implemented in the = solution and so developing support for something like CSCP would be seen as a burden=94. I can=92t figure out if you WILL implement BFCP, and thus = CSCP is easy, or you won=92t implement BFCP because it=92s not mandatory and = thus CSCP would be a burden. I think if you implement BFCP then CSCP is = relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to = expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 _____ =20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent = Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. =20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the = proposals and will be providing questions and feedback in individual mails. This = mail is an attempt to discuss some architectural decisions that I personally = feel are equally as important. As some of you may already know, I am a = supporter of the SOAP proposals (Henning, myself and Mary) that are currently = being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by =91who exactly will be a conference client = manipulating Conference Objects?=92 As an application server vendor who=92s product = very much utilises web services. SOAP seems the obvious choice. From a = handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services = using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web = services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON = allowing both a handset friendly interface such as CSCP and a SOAP interface for = web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long = as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that = this is the best solution to make XCON appealing to a wide variety of = architectures. =20 I=92m going to duck now and wait for incoming bullets but on a serious = note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended = for the use of the addressee only, and may contain confidential information = of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, = please notify the sender immediately and destroy all copies of this email. = Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to = be legally binding. Thank-you=20 ------=_NextPart_000_0304_01C62331.1CA06080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Okay, so, we could talk about two = bindings for one data model/interaction model if we wanted to.=A0 =

An interesting question follows = from that: would you want a SOAP based binding for floor = control?

Brian

From: Chris = Boulton [mailto:cboulton@ubiquity.net]
Sent: Friday, January 27, = 2006 11:00 AM
To: Oscar Novo (JO/LMF); = br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

I think it=B4s = quite obvious. :)

But anyway, = still all the systems have to implement the SOAP protocol from the scratch and = this is not the case of CSCP even if the systems that support the BFCP are low.

Don=B4t be mad = at me. :)

=
[Chris Boulton] hehehe – how could I. = This isn’t a ‘vs’ debate – I’m just saying that = if you have got a web services SOAP interface, it would be useful for XCON to = provide hooks so that clients (e.g. J2EE applications not UA’s or = handsets) can control conferences using mechanisms that they find common e.g. SOAP, = WSDL, UDDI. I agree that this Conference System would almost certainly = have a BFCP interface (and therefore a CSCP interface), but my client = application would probably not.

From: Chris Boulton [mailto:cboulton@ubiquity.net]
Sent: 27. tammikuuta 2006 = 17:43
To: Oscar Novo (JO/LMF); = br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

Chris,

Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this = comments based on?

So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from = scratch.

Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: 27. tammikuuta 2006 = 17:13
To: br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

Hi = Brian,

Clarification in-line.

Chris.

-----Original = Message-----
From: Brian Rosen = [mailto:br@brianrosen.net]
Sent: 27 January 2006 = 14:27
To: Chris Boulton; = xcon@ietf.org
Cc: ajohnston@tello.com; = 'Adam Roach'
Subject: RE: [XCON] = Conference Control

I’m not opposed to having two bindings to the same interface, but I would = not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport = being different. I’m not sure that would be particularly = interesting to you.

Also, could you clarify your statements on CSCP? What you said was = “it may be likely, as it is not mandatory, that BFCP be implemented in the = solution and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement = BFCP, and thus CSCP is easy, or you won’t implement BFCP because it’s = not mandatory and thus CSCP would be a burden. I think if you = implement BFCP then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework = reads:

Floor control is not a mandatory mechanism = for a conferencing system implementation but provides advanced media = input control features for conference = users.

So the point I was trying to convey = was that BFCP, as it stands in the Framework is not mandatory. So for an = element wanting to use just CSCP would have to develop from scratch. In = this scenario, just having to expose a WSDL initiated web interface is = preferred.

Chris.

Brian

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On = Behalf Of Chris Boulton
Sent: Friday, January 27, = 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: [XCON] = Conference Control

Hi = All,

Just wanted to = generate some discussion relating to the recent Conference Control = submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I = realise that the thoughts conveyed in this mail are a little controversial, I thought I = would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be = providing questions and feedback in individual mails. This mail is an = attempt to discuss some architectural decisions that I personally feel are equally = as important. As some of you may already know, I am a supporter of = the SOAP proposals (Henning, myself and Mary) that are currently being worked = on. This led me to realise that my preference was being swayed (purely = selfish :-) by ‘who exactly will be a conference client manipulating = Conference Objects?’ As an application server vendor who’s = product very much utilises web services. SOAP seems the obvious choice. From a = handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services = using web services it may be likely, as it is not mandatory, that BFCP be = implemented in the solution and so developing support for something like CSCP would = be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our = clients.

It is for = these reasons that I was pondering the prospect of XCON allowing both a handset = friendly interface such as CSCP and a SOAP interface for web services where the = client might well be another application and not a handset. I realise = that having two interfaces is not ideal, but as long as we are careful in our = rules on minimal implementation and ability to advertise capabilities to a = Conference Client I personally feel that this is the best solution to make XCON = appealing to a wide variety of architectures.

I’m = going to duck now and wait for incoming bullets but on a serious note I strongly = appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming = months.

Best = Regards,

Chris = Boulton.

Information contained in = this e-mail and any attachments are intended for the use of the addressee = only, and may contain confidential information of Ubiquity Software Corporation. = All unauthorized use, disclosure or distribution is strictly = prohibited. If you are not the addressee, please notify the sender immediately and = destroy all copies of this email. Unless otherwise expressly agreed in writing = signed by an officer of Ubiquity Software Corporation, nothing in this = communication shall be deemed to be legally binding. Thank-you =

------=_NextPart_000_0304_01C62331.1CA06080-- --===============0062374533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0062374533==-- From xcon-bounces@ietf.org Fri Jan 27 11:10:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WAo-00078Y-CQ; Fri, 27 Jan 2006 11:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WAl-00077V-Lc for xcon@megatron.ietf.org; Fri, 27 Jan 2006 11:10:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22512 for ; Fri, 27 Jan 2006 11:08:30 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WKw-0004eK-5x for xcon@ietf.org; Fri, 27 Jan 2006 11:20:35 -0500 Received: from rly29b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly29b.srv.mailcontrol.com (MailControl) with ESMTP id k0RG9JaM008650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 16:09:51 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly29b.srv.mailcontrol.com (MailControl) id k0RG8wUL007982 for xcon@ietf.org; Fri, 27 Jan 2006 16:08:58 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly29b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0RG8shx007835; Fri, 27 Jan 2006 16:08:58 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 16:08:54 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78A99@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAAAhNRAAAFaOQAAAMuRAAAA4QZA= From: "Chris Boulton" To: , "Oscar Novo $JO/LMF$" , X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.139 X-Spam-Score: 0.3 (/) X-Scan-Signature: ddfd5a9c868cfab7d9493f20ea6d0fa3 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0285822040==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0285822040== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6235B.F85AF410" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6235B.F85AF410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Okay, so, we could talk about two bindings for one data model/interaction m= odel if we wanted to.=20=20 =20 =20 An interesting question follows from that: would you want a SOAP based bind= ing for floor control? =20 [Chris Boulton] I was actually musing the same question as I received yours= . I certainly think it would be useful. =20 Brian =20 _____=20=20 From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Friday, January 27, 2006 11:00 AM To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 =20 I think it=B4s quite obvious. :)=20 But anyway, still all the systems have to implement the SOAP protocol from= the scratch and this is not the case of CSCP even if the systems that supp= ort the BFCP are low.=20 =20 Don=B4t be mad at me. :) =20 [Chris Boulton] hehehe - how could I. This isn't a 'vs' debate - I'm just = saying that if you have got a web services SOAP interface, it would be usef= ul for XCON to provide hooks so that clients (e.g. J2EE applications not UA= 's or handsets) can control conferences using mechanisms that they find com= mon e.g. SOAP, WSDL, UDDI. I agree that this Conference System would almos= t certainly have a BFCP interface (and therefore a CSCP interface), but my = client application would probably not.=20 =20 =20 _____=20=20 From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: 27. tammikuuta 2006 17:43 To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP even = thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from scratch= but If SOAP is going to be the protocol all the conference systems have to= develop the protocol from scratch. =20 Oscar _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chr= is Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would n= ot want to see two interfaces. That means the models, data structures, ope= rations, errors, etc would have to be identical, with only transport being = different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may= be likely, as it is not mandatory, that BFCP be implemented in the solutio= n and so developing support for something like CSCP would be seen as a burd= en". I can't figure out if you WILL implement BFCP, and thus CSCP is easy,= or you won't implement BFCP because it's not mandatory and thus CSCP would= be a burden. I think if you implement BFCP then CSCP is relatively less w= ork from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implem= entation but provides advanced media input control features for conference = users. =20 So the point I was trying to convey was that BFCP, as it stands in the Fram= ework is not mandatory. So for an element wanting to use just CSCP would h= ave to develop from scratch. In this scenario, just having to expose a WSD= L initiated web interface is preferred. Chris. =20 =20 Brian =20 _____=20=20 From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chr= is Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference C= ontrol submissions. I would like to begin by thanking all the relevant par= ties for the effort contributed before Christmas.=20=20 =20 While I realise that the thoughts conveyed in this mail are a little contro= versial, I thought I would poke my head up into the firing line in attempt = to stimulate some discussion. I have reviewed all of the proposals and wil= l be providing questions and feedback in individual mails. This mail is an= attempt to discuss some architectural decisions that I personally feel are= equally as important. As some of you may already know, I am a supporter o= f the SOAP proposals (Henning, myself and Mary) that are currently being wo= rked on. This led me to realise that my preference was being swayed (purel= y selfish :-) by 'who exactly will be a conference client manipulating Conf= erence Objects?' As an application server vendor who's product very much u= tilises web services. SOAP seems the obvious choice. From a handset vendor= I can also see that proposals such as CCCP and CSCP are more appealing. A= s an application server offering conferencing services using web services i= t may be likely, as it is not mandatory, that BFCP be implemented in the so= lution and so developing support for something like CSCP would be seen as a= burden, especially as we already have a web services interface that provid= es all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing = both a handset friendly interface such as CSCP and a SOAP interface for web= services where the client might well be another application and not a hand= set. I realise that having two interfaces is not ideal, but as long as we = are careful in our rules on minimal implementation and ability to advertise= capabilities to a Conference Client I personally feel that this is the bes= t solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I= strongly appeal to all who are interested on making Dallas a productive me= eting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribut= ion is strictly prohibited. If you are not the addressee, please notify th= e sender immediately and destroy all copies of this email. Unless otherwis= e expressly agreed in writing signed by an officer of Ubiquity Software Cor= poration, nothing in this communication shall be deemed to be legally bindi= ng. Thank-you=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C6235B.F85AF410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Okay, so, we could talk about two bindings for one data model/interaction model i= f we wanted to.

=

= An interesting question follows from that: would you want a SOAP based binding= for floor control?

=

[Chris Boulton] I was actually musing the same question = as I received yours. =A0I certainly think it would be useful.<= /b>

= Brian

=

From:= = Chris Boulton [mailto:cboulton@ubiquity.net]
Sent: Fr= iday, January 27, 2006 11:00 AM=
To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conferen= ce Control

=

= I think it=B4s quite obvious. :)

= But anyway, still all the systems have to implement the SOAP protocol from the scratch and this is not the case of CSCP even if the systems that suppo= rt the BFCP are low.

= Don=B4t be mad at me. :)

=

[Chris Boulton] hehehe – how coul= d I. This isn’t a ‘vs’ debate – I’m just say= ing that if you have got a web services SOAP interface, it would be useful for = XCON to provide hooks so that clients (e.g. J2EE applications not UA’s or handsets) can control conferences using mechanisms that they find common e.= g. SOAP, WSDL, UDDI. I agree that this Conference System would almost certainly have a BFCP interface (and therefore a CSCP interface), but my cl= ient application would probably not.

From: Chris Boulton [mailto:cboulton@ubiquity.net]
Sent: 27. tammikuuta 2006 17:43=
To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conferen= ce Control

= Chris,

= Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this comm= ents based on?

= So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch.

= Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behal= f Of Chris Boulton
Sent: 27. tammikuuta 2006 17:13=
To: br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conferen= ce Control

= Hi Brian,

= Clarification in-line.

= Chris.

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: 27= January 2006= 14:27=
To: Chris Boulton; xcon@ietf= .org
Cc: ajohnston@tello.com; 'Ad= am Roach'
Subject: RE: [XCON] Conferen= ce Control

= I’m not opposed to having two bindings to the same interface, but I would not w= ant to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport bei= ng different. I’m not sure that would be particularly interesting = to you.

= Also, could you clarify your statements on CSCP? What you said was “<= /span>it may be likely, as it is not mandatory, that BFCP be implemented in the solu= tion and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement BFCP, a= nd thus CSCP is easy, or you won’t implement BFCP because it’s not mandatory and thus CSCP would be a burden. I think if you implement B= FCP then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework read= s:

Floor control is not a mandatory mechanism for a= conferencing system implementation but provides advanced media input contr= ol features for conference users.

So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. = In this scenario, just having to expose a WSDL initiated web interface is preferred.

Chris.

= Brian

From:= xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Fr= iday, January 27, 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference C= ontrol

Hi All,

Just wanted to ge= nerate some discussion relating to the recent Conference Control submissions. = ; I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I realise t= hat the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the S= OAP proposals (Henning, myself and Mary) that are currently being worked on.&nb= sp; This led me to realise that my preference was being swayed (purely selfish = :-) by ‘who exactly will be a conference client manipulating Conference Objects?’ As an application server vendor who’s product v= ery much utilises web services. SOAP seems the obvious choice. From a han= dset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services us= ing web services it may be likely, as it is not mandatory, that BFCP be impleme= nted in the solution and so developing support for something like CSCP would be = seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these r= easons that I was pondering the prospect of XCON allowing both a handset friendly = interface such as CSCP and a SOAP interface for web services where the client might w= ell be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on mini= mal implementation and ability to advertise capabilities to a Conference Client= I personally feel that this is the best solution to make XCON appealing to a = wide variety of architectures.

I’m going t= o duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making = Dallas a productive meeting to comment on mails such as this over the coming month= s.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, = and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. = If you are not the addressee, please notify the sender immediately and destroy= all copies of this email. Unless otherwise expressly agreed in writing si= gned by an officer of Ubiquity Software Corporation, nothing in this communicati= on shall be deemed to be legally binding. Thank-you

------_=_NextPart_001_01C6235B.F85AF410-- --===============0285822040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0285822040==-- From xcon-bounces@ietf.org Fri Jan 27 11:10:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WBS-0007Ir-PQ; Fri, 27 Jan 2006 11:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WBQ-0007Hh-C4 for xcon@megatron.ietf.org; Fri, 27 Jan 2006 11:10:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22560 for ; Fri, 27 Jan 2006 11:09:11 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WLb-0004fr-7S for xcon@ietf.org; Fri, 27 Jan 2006 11:21:16 -0500 Received: from lion.cs.columbia.edu (IDENT:Spb6Q1s4qeP6x6ptIdXs0Uc/3THURePF@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0RG7ZKG016669 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 27 Jan 2006 11:10:41 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0RG7YnE018140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jan 2006 11:07:35 -0500 Message-ID: <43DA4544.20409@cs.columbia.edu> Date: Fri, 27 Jan 2006 11:07:32 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] Conference Control References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id k0RG7ZKG016669 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Compared to implementing the logic of conference control, the=20 encapsulation is a tiny fraction of the work, particularly given that=20 you can get SOAP stacks pre-packaged for almost any conceivable platform=20 and language, mobile or otherwise. (A SOAP client is nothing more than a=20 bit of XML on top of HTTP, so you don't even need a stack, just an XML=20 parser and an HTTP client library, both of which any SIP-speaking device=20 will need in any event.) Thus, I don't think this is much of a differentiator. Oscar Novo (JO/LMF) wrote: > I think it=B4s quite obvious. :) > But anyway, still all the systems have to implement the SOAP protocol=20 > from the scratch and this is not the case of CSCP even if the systems=20 > that support the BFCP are low.=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 27 12:28:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2XOr-0001zj-4g; Fri, 27 Jan 2006 12:28:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2XOp-0001zZ-3y for xcon@megatron.ietf.org; Fri, 27 Jan 2006 12:28:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28685 for ; Fri, 27 Jan 2006 12:27:05 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2XYy-0007Fg-5s for xcon@ietf.org; Fri, 27 Jan 2006 12:39:11 -0500 Received: from rly23b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly23b.srv.mailcontrol.com (MailControl) with ESMTP id k0RHSK08002753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 17:28:20 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly23b.srv.mailcontrol.com (MailControl) id k0RHS2ar002342 for xcon@ietf.org; Fri, 27 Jan 2006 17:28:02 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly23b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0RHS1cC002315; Fri, 27 Jan 2006 17:28:02 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 17:28:01 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78A9B@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjXqFUItA5QWwnRsSS/PyrRfgVYgACD95Q From: "Chris Boulton" To: "Henning Schulzrinne" , "Oscar Novo $JO/LMF$" X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.133 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Compared to implementing the logic of conference control, the=20 encapsulation is a tiny fraction of the work, particularly given that=20 you can get SOAP stacks pre-packaged for almost any conceivable platform=20 and language, mobile or otherwise. (A SOAP client is nothing more than a=20 bit of XML on top of HTTP, so you don't even need a stack, just an XML=20 parser and an HTTP client library, both of which any SIP-speaking device=20 will need in any event.) [Chris Boulton] Agreed. Thus, I don't think this is much of a differentiator. [Chris Boulton] Either way - I am fed up of it being 'the only' differentia= tor. Oscar Novo (JO/LMF) wrote: > I think it=B4s quite obvious. :) > But anyway, still all the systems have to implement the SOAP protocol=20 > from the scratch and this is not the case of CSCP even if the systems=20 > that support the BFCP are low.=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 27 13:01:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Xup-0007iI-Kj; Fri, 27 Jan 2006 13:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Xuo-0007iC-LC for xcon@megatron.ietf.org; Fri, 27 Jan 2006 13:01:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00726 for ; Fri, 27 Jan 2006 13:00:06 -0500 (EST) Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Y4z-0008C2-3l for xcon@ietf.org; Fri, 27 Jan 2006 13:12:13 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0RI1Jw04406; Fri, 27 Jan 2006 13:01:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Date: Fri, 27 Jan 2006 12:01:04 -0600 Message-ID: Thread-Topic: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Thread-Index: AcYMZzIybMjYcXK1TheBLMyVNAiSUAAFn9UwAD48vPAFfPYjIA== From: "Mary Barnes" To: , "Henning" X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Although, I don't want to distract from the main discussion ongoing on the protocol, I would like us to close off on these issues around the data. =20 In re-reading this thread, I'm wondering if Brian and Henning aren't fundamentally arguing that the template (i.e. the object conformant to the schema as defined by a specific template) is not in the same object as the common conference information (i.e. the "out"=20 position)? Otherwise, is the proposed text okay? If not, please propose alternative wording. Thanks, Mary -----Original Message----- From: Barnes, Mary [RICH2:B601:EXCH]=20 Sent: Friday, December 30, 2005 1:45 PM To: 'br@brianrosen.net'; 'Henning' Cc: xcon@ietf.org Subject: RE: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) I'm concerned that we may not all be on the same page. I generally agree with Brian's and Henning's statements. The clarification I would add is that the Blueprint also contains the Common Conference Information, so it's more than just a set of initial values assigned to an object conformant to the schema defined for the template. The blueprint also contains the intial values and ranges for the elements defined by the common conference information schema.=20 If there's agreement that the blueprint also contains common conference information, then we need to figure out where we need to clarify the text in the framework document so that everyone reading the document understands that and we also need to add text to emphasize the point you two have made. I agree the current definition of Blueprint is slightly fuzzy on the relationship between the template and the blueprint. Perhaps, changing the last sentence of the definition would help. So, I would propose a change from: "A system may maintain multiple blueprints, each comprised of the common conference information, along with any number of templates." to: "A system may maintain multiple blueprints. Each blueprint is=20 comprised of the initial values and ranges for the elements in=20 the object, conformant to the data schemas for the common=20 conference information and the specific template(s) associated=20 with the blueprint." If you both are saying that the Blueprint does not contain common conference information, then we need more discussion and input from others, as well, as alot more proposed text changes for the document.=20 Mary -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, December 29, 2005 7:46 AM To: 'Henning'; Barnes, Mary [RICH2:B601:EXCH] Cc: xcon@ietf.org Subject: RE: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) FWIW, my conception of Blueprint is the same as Henning's. A template is a definition; there is a document that describes it, and probably something like a schema. =20 The Blueprint is the set of initial values assigned to an object conformant to the schema.=20 Brian =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Sent: Thursday, December 29, 2005 5:57 AM To: Mary Barnes Cc: xcon@ietf.org Subject: Re: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Your note makes me worry that I still don't understand the template concept. I had earlier provided a brief definition of a template. Is that in=20 agreement with yours? In short: Template =3D class definition (data types); blueprint =3D = initial=20 values (dynamic). Obviously, a blueprint only makes sense within a=20 particular template. ----- Original Message -----=20 From: "Mary Barnes" To: "Henning Schulzrinne" Cc: Sent: Wednesday, December 28, 2005 5:03 PM Subject: RE: [XCON] DP4/4.1: Common Conference Information and=20 Templates(in/out problem) >I think the objective is as you state in that everything in the end does > get created from a blueprint (basic or customized). > > We were debating how customizable are the templates - I guess I don't > see the impact on the inheritance model. If there doesn't seem to be > the need for this "by-reference" and multiple templates concept, then > that does simplify things (but restricts future flexibility and > applicability of the framework). I guess it might be reasonable at this > point to suggest that the data model and associated protocols will only > support the by-value and a single template model initially. [That seems > to be what Brian Rosen is also arguing for in his response.] > > Mary > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, December 24, 2005 8:08 AM > To: Barnes, Mary [RICH2:B601:EXCH] > Cc: xcon@ietf.org > Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates > (in/out problem) > > > I'm concerned that we're adding too many related, but subtly, different > inheritance concepts. > > I'm still not quite sure I understand blueprints, but as described > below, this seems awfully close to the concept of inheritance of > individual instances ("tree"). > > Thus, I wonder if the two concepts can't be unified. Essentially, a > "blueprint" becomes the root of the inheritance tree. > > That way, we only have one dynamic (value) inheritance concept. This > also makes it easy to create custom inheritance, such as "our weekly > departmental meeting". It simply gets created from one of the > system-defined 'blueprints'. > > Henning > > Mary Barnes wrote: >> Hi all, >> >> There's been a group of us (XCON FW authors, current template authors >> and data model authors) discussing this point and a couple of related >> issues around the Common conference information, templates and >> blueprints offline since the IETF meeting. We've come to tenuous >> agreement amongst ourselves on a couple of aspects of this topic and >> wanted to continue and complete the discussion with the WG. I'm >> summarizing the issues and the changes proposed at this point to the >> framework to accomodate current thinking. I've labeled the related >> questions/topics we've discussed for convenience as DP4.2 and DP4.3 > and >> I'll post those in separate threads to facilitate tracking the issues. >> Feedback would be appreciated - ideally supported by alternative > and/or >> additional text . >> >> Per discussion at the IETF-64, there still seemed to be some debate >> (beyond the basic data model approach discussed in the "Call for >> Consensus:Data model" thread initiated by Adam) on some fundamentals > of >> the model defined in the framework. Basically, this is the DP4 issue > as >> to whether the template is in the same object as the common conference >> information (i.e. "in") or whether it is a separate object (i.e. > "out"). >> The framework has been based on the "in" concept barring any other >> conclusion by the WG, noting that the current definition of blueprint > is >> quite explicit about this: >> "A conference blueprint is a static conference >> object within a conferencing system, which describes a typical >> conference setting supported by the system. A conference >> blueprint is the basis for creation of dynamic conference > objects. >> A system may maintain multiple blueprints, each comprised of the >> common conference information, along with any number of >> templates." >> >> The discussion amongst the group seemed to lead to it's not being an >> in/out issue as much as it is either by-value or by-reference. It was >> suggested that we just chooose by-value for now, but that wasn't > deemed >> practical in terms of the model put forth in the framework in terms of >> lots of flexibility, with optionality of templates. We did (tenuously) >> agree to support both. The Blueprint concept really requires that we >> support by-reference, and that's consistent with the current approach >> whereby the client fetches any templates from the server that it > doesn't >> understand. At the same time, a barebones system could initially just >> support a few templates and by-value might make sense. But, again, I >> think it's too limiting for the vision represented in the framework to >> be the only option supported. >> >> At this time, we're proposing something like the following be added >> after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" >> section that introduces the blueprint concept) supporting the concept > of >> by-value or by-reference. It might be useful to add more text > including >> some background for the context for using one or the other, as well: >> "As defined within this framework, a blueprint is comprised of the >> common conference information and one or more templates. The > templates >> within the blueprint can either be included by-value or by-reference >> depending upon the system implementation." >> >> Mary. >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 27 13:18:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2YBT-0006X9-D0; Fri, 27 Jan 2006 13:18:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2YBS-0006Wt-0y for xcon@megatron.ietf.org; Fri, 27 Jan 2006 13:18:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02217 for ; Fri, 27 Jan 2006 13:17:20 -0500 (EST) Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2YLe-0000N2-RX for xcon@ietf.org; Fri, 27 Jan 2006 13:29:27 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0RIIWw09405; Fri, 27 Jan 2006 13:18:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] DP4.2: Defining new templates Date: Fri, 27 Jan 2006 12:18:29 -0600 Message-ID: Thread-Topic: [XCON] DP4.2: Defining new templates Thread-Index: AcYIHrZ2puiNOKyuSUWfCpCZ+pq0aQDovrtwBeqDfxA= From: "Mary Barnes" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org In re-reviewing this thread (to which no one has responded thus far on the list), I think Brian is arguing for simplicity - i.e., do we really need this flexibility in dynamic controls?. =20 My personal viewpoint, is that given where we are in trying to complete this work, that simplicity would be a good objective, unless someone has a compelling reason why that's not at all acceptable. Initially, I was considering it advantageous for the framework to be extremely flexible, but it seems that allowing too much flexibility is leading to confusion over the basic functionality provided by the framework. =20 So, I'm proposing to modify the proposed change below and include the following text at the end of the last paragraph in section 5.2: "The addition of new elements or the modification of the controls within an element of an existing template requires the definition of a new template." Note, that the last paragraph of section 5.2 discusses the concept of an abstract user interface definition and I think that's still okay: " A conference template can also include an abstract user interface definition in terms of sliders, radio boxes, etc. for simplifying user interaction with a specific non-trivial feature. " If folks don't agree, please respond and propose alternative text. Thanks, Mary -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, December 28, 2005 9:30 AM To: Barnes, Mary [RICH2:B601:EXCH]; xcon@ietf.org Subject: RE: [XCON] DP4.2: Defining new templates So, I'm not sure I like this. Generally, I like some flexibility, so, generally, I hate saying "you can't". OTOH, we are talking about something that is primarily a user interface, about which I have a reasonable amount of experience. From that experience, I can say that a well designed client would NOT APPRECIATE hearing from a server that this particular server happens to have added a few dozen minor controls, and would the client please dynamically render them in addition to those carefully designed by a quality user interface designer to meet a specification. It is NOT a matter of saying, "well no one forces you to use those controls". As we all know, the likelihood is that, actually, it won't really work, in the sense that the user won't have a good experience, if the controls aren't rendered. If you want a good user experience, you don't have variations from server to server for a well designed client; they all work the same. For that reason, I think we are best to NOT have this flexibility. I've gone along with people who want to retain the ability for a client to connect to a server, discover that a conference uses a template it doesn't understand, and attempts to render a user interface for it. I think users will not like the result, but, hey, there might be a genius out there who can make it work. It doesn't stop a well designed client who implements the template from doing its work well. Allowing a server to dynamically add controls would. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, December 23, 2005 7:12 PM To: xcon@ietf.org Subject: [XCON] DP4.2: Defining new templates One of the points we discussed was: DP4.2 Whether clients can dynamically use new templates or whether new templates require new SW in clients? The current wording in the framework supports the former proposal,=20 specifically, section 7.3 currently states: "A client may need to query any templates in the blueprints that it doesn't understand and then make a decision on compatibility." Part of the confusion here (at least for me) is over what is meant by "new". There seemed to be unanimous agreement that a client can query a template that it doesn't currently have or has not previously used. That isn't the same thing as saying that templates can be dynamically created by a conferencing system. Per the framework, all the templates used by a conferencing system must be documented and registered. So, the discussion ended up being more around what could be changed within a template without requiring SW changes. After discussion, the group of authors seemed to agree that while modifications in the form of new controls added to elements of a template could be done without the need to register anything or define a new template, but adding new elements does require appropriate documentation and registration (i.e. a client can't be expected to understand new elements).=20 To clarify this, we could reasonably add something like the following the 2nd paragraph in section 5.2, which introduces the template concept: "It should be possible to modify the controls within an element of an existing template, without defining a new template. The client can than attempt to render the modified element to make use of the potential new functionality. However, adding new elements does require defining an entirely new template as discussed in the previous paragraph." Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 27 18:21:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2cuc-0001ag-JY; Fri, 27 Jan 2006 18:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2cuY-0001Zv-D8 for xcon@megatron.ietf.org; Fri, 27 Jan 2006 18:21:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25494 for ; Fri, 27 Jan 2006 18:20:12 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2d4l-0003C3-LX for xcon@ietf.org; Fri, 27 Jan 2006 18:32:22 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Jan 2006 15:21:33 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 15:21:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 15:21:32 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 15:21:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 15:21:28 -0800 Message-ID: In-Reply-To: <02ea01c62359$5e5ea400$651f0a0a@cis.neustar.com> Thread-Topic: [XCON] Conference Control thread-index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAAAv9IAAD9sKcA== From: "Sean Olson" To: , "Chris Boulton" , "Oscar Novo $JO/LMF$" , X-OriginalArrivalTime: 27 Jan 2006 23:21:32.0660 (UTC) FILETIME=[68C85B40:01C62398] X-Spam-Score: 0.4 (/) X-Scan-Signature: e1de2149c0c23c6675e98c918b359cf3 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2076321277==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2076321277== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62398.68798964" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62398.68798964 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have to disagree .... you can have extremely feature rich conferencing clients without a floor control protocol. ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, January 27, 2006 7:50 AM To: 'Chris Boulton'; 'Oscar Novo (JO/LMF)'; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control I guess that this is whether floor control is seen as a "must have" feature in a conference client. Basically, I think that if you need any more than the basic conference control that comes with nothing more than the conference package and other SIP mechanisms; that is, you implement the conference control package, you have a rich enough client that floor control would be essential. I'd be hard pressed to think of a client that would have the conference control package without floor control. It's POSSIBLE, but I don't think its probable. Floor control is kind of a fundamental thing beyond the simplistic kinds of conferences that don't need any of the xcon stuff. =20 Brian =20 ________________________________ From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Friday, January 27, 2006 10:42 AM To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch. =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. =20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 ------_=_NextPart_001_01C62398.68798964 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have to disagree .... you can have extremely = feature rich=20 conferencing clients without a floor control = protocol.

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent:=20 Friday, January 27, 2006 7:50 AM
To: 'Chris Boulton'; 'Oscar = Novo=20 (JO/LMF)'; xcon@ietf.org
Cc: ajohnston@tello.com; 'Adam=20 Roach'
Subject: RE: [XCON] Conference = Control

I guess that = this is=20 whether floor control is seen as a “must have” feature in a = conference=20 client.

Basically, I = think that=20 if you need any more than the basic conference control that comes with = nothing=20 more than the conference package and other SIP mechanisms; that is, you=20 implement the conference control package, you have a rich enough client = that=20 floor control would be essential. I’d be hard pressed to = think of a client=20 that would have the conference control package without floor control. = It’s=20 POSSIBLE, but I don’t think its probable. Floor control is = kind of a=20 fundamental thing beyond the simplistic kinds of conferences that = don’t need any=20 of the xcon stuff.

Brian

From: Chris=20 Boulton [mailto:cboulton@ubiquity.net]
Sent: Friday, January 27, 2006 = 10:42=20 AM
To: Oscar Novo = (JO/LMF);=20 br@brianrosen.net;=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; Adam Roach
Subject: RE: [XCON] Conference=20 Control

Chris,

Notice=20 that almost all the conference systems will implement the BFCP even=20 thought it is not compulsory.

[Chris=20 Boulton] What proof is this comments based=20 on?

So,=20 at the end few systems would have to develop the protocol from scratch=20 but If SOAP is going to be the protocol all the conference=20 systems have to develop the protocol from=20 scratch.

Oscar

From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent: 27. tammikuuta 2006 = 17:13
To: br@brianrosen.net; = xcon@ietf.org
Cc: ajohnston@tello.com; Adam=20 Roach
Subject: RE: = [XCON]=20 Conference Control

Hi=20 Brian,

Clarification = in-line.

Chris.

-----Original=20 Message-----
From: = Brian Rosen=20 [mailto:br@brianrosen.net]=20
Sent: 27 January = 2006=20 14:27
To: Chris = Boulton;=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; 'Adam Roach'
Subject: RE: [XCON] Conference=20 Control

I’m not=20 opposed to having two bindings to the same interface, but I would not = want to=20 see two interfaces. That means the models, data structures, = operations,=20 errors, etc would have to be identical, with only transport being=20 different. I’m not sure that would be particularly = interesting to=20 you.

Also,=20 could you clarify your statements on CSCP? What you said was=20 “it may be likely, as it is = not=20 mandatory, that BFCP be implemented in the solution and so developing = support=20 for something like CSCP would be seen as a burden”. I = can’t figure out if=20 you WILL implement BFCP, and thus CSCP is easy, or you won’t = implement BFCP=20 because it’s not mandatory and thus CSCP would be a burden. = I think if you=20 implement BFCP then CSCP is relatively less work from there.=20

[Chris=20 Boulton] The XCON Framework = reads:
Floor control is not a mandatory mechanism for a conferencing = system implementation but provides advanced media input control features = for conference users.

So=20 the point I was trying to convey was that BFCP, as it stands in the = Framework is=20 not mandatory. So for an element wanting to use just CSCP would = have to=20 develop from scratch. In this scenario, just having to expose a = WSDL=20 initiated web interface is = preferred.

Chris.

Brian

From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris = Boulton
Sent: Friday, January 27, 2006 = 5:01=20 AM
To:=20 xcon@ietf.org
Cc:=20 ajohnston@tello.com; Adam Roach
Subject: [XCON] Conference=20 Control

Hi=20 All,

Just wanted = to generate=20 some discussion relating to the recent Conference Control = submissions. I=20 would like to begin by thanking all the relevant parties for the effort=20 contributed before Christmas.

While I = realise that the=20 thoughts conveyed in this mail are a little controversial, I thought I = would=20 poke my head up into the firing line in attempt to stimulate some=20 discussion. I have reviewed all of the proposals and will be = providing=20 questions and feedback in individual mails. This mail is an = attempt to=20 discuss some architectural decisions that I personally feel are equally = as=20 important. As some of you may already know, I am a supporter of = the SOAP=20 proposals (Henning, myself and Mary) that are currently being worked = on. =20 This led me to realise that my preference was being swayed (purely = selfish :-)=20 by ‘who exactly will be a conference client manipulating = Conference=20 Objects?’ As an application server vendor who’s = product very much utilises=20 web services. SOAP seems the obvious choice. From a handset vendor = I can=20 also see that proposals such as CCCP and CSCP are more appealing. = As an=20 application server offering conferencing services using web services it = may be=20 likely, as it is not mandatory, that BFCP be implemented in the solution = and so=20 developing support for something like CSCP would be seen as a burden, = especially=20 as we already have a web services interface that provides all the = relevant=20 infrastructure to link to our clients.

It is for = these reasons=20 that I was pondering the prospect of XCON allowing both a handset = friendly=20 interface such as CSCP and a SOAP interface for web services where the = client=20 might well be another application and not a handset. I realise = that having=20 two interfaces is not ideal, but as long as we are careful in our rules = on=20 minimal implementation and ability to advertise capabilities to a = Conference=20 Client I personally feel that this is the best solution to make XCON = appealing=20 to a wide variety of architectures.

I’m = going to duck now and=20 wait for incoming bullets but on a serious note I strongly appeal to all = who are=20 interested on making Dallas a productive meeting to = comment on mails=20 such as this over the coming months.

Best=20 Regards,

Chris=20 Boulton.

Information contained = in this=20 e-mail and any attachments are intended for the use of the addressee = only, and=20 may contain confidential information of Ubiquity Software Corporation. = All=20 unauthorized use, disclosure or distribution is strictly = prohibited. If=20 you are not the addressee, please notify the sender immediately and = destroy all=20 copies of this email. Unless otherwise expressly agreed in writing = signed=20 by an officer of Ubiquity Software Corporation, nothing in this = communication=20 shall be deemed to be legally binding. Thank-you=20
------_=_NextPart_001_01C62398.68798964-- --===============2076321277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============2076321277==-- From xcon-bounces@ietf.org Fri Jan 27 18:26:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2cz8-0004In-2K; Fri, 27 Jan 2006 18:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2cz6-0004If-IT for xcon@megatron.ietf.org; Fri, 27 Jan 2006 18:26:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25866 for ; Fri, 27 Jan 2006 18:24:55 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2d9M-0003LZ-3j for xcon@ietf.org; Fri, 27 Jan 2006 18:37:04 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Jan 2006 15:26:18 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 15:26:18 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 15:26:18 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 15:26:17 -0800 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 Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 15:26:16 -0800 Message-ID: In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78A9B@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control thread-index: AcYjXqFUItA5QWwnRsSS/PyrRfgVYgACD95QAAxu4nA= From: "Sean Olson" To: "Chris Boulton" , "Henning Schulzrinne" , "Oscar Novo $JO/LMF$" X-OriginalArrivalTime: 27 Jan 2006 23:26:17.0957 (UTC) FILETIME=[12D53950:01C62399] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org I think Chris' proposal is very reasonable. Why is this an either-or = discussion? Why not allow multiple bindings? I think it would be a = mistake to create a least common denominator approach to satisfy the = constraints of CPU/bandwidth limited devices. =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Chris Boulton Sent: Friday, January 27, 2006 9:28 AM To: Henning Schulzrinne; Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control Compared to implementing the logic of conference control, the = encapsulation is a tiny fraction of the work, particularly given that = you can get SOAP stacks pre-packaged for almost any conceivable platform = and language, mobile or otherwise. (A SOAP client is nothing more than a = bit of XML on top of HTTP, so you don't even need a stack, just an XML = parser and an HTTP client library, both of which any SIP-speaking device = will need in any event.) [Chris Boulton] Agreed. Thus, I don't think this is much of a differentiator. [Chris Boulton] Either way - I am fed up of it being 'the only' = differentiator. Oscar Novo (JO/LMF) wrote: > I think it=B4s quite obvious. :) > But anyway, still all the systems have to implement the SOAP protocol = > from the scratch and this is not the case of CSCP even if the systems=20 > that support the BFCP are low. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon Information contained in this e-mail and any attachments are intended = for the use of the addressee only, and may contain confidential = information of Ubiquity Software Corporation. All unauthorized use, = disclosure or distribution is strictly prohibited. If you are not the = addressee, please notify the sender immediately and destroy all copies = of this email. Unless otherwise expressly agreed in writing signed by = an officer of Ubiquity Software Corporation, nothing in this = communication shall be deemed to be legally binding. Thank you. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jan 27 18:31:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2d3u-0005rA-8A; Fri, 27 Jan 2006 18:31:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2d3q-0005md-VU for xcon@megatron.ietf.org; Fri, 27 Jan 2006 18:31:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26087 for ; Fri, 27 Jan 2006 18:29:48 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2dE5-0003Rz-P1 for xcon@ietf.org; Fri, 27 Jan 2006 18:41:58 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F2d3a-0000Ys-Qp; Fri, 27 Jan 2006 17:31:07 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Chris Boulton'" , "'Henning Schulzrinne'" , "'Oscar Novo $JO/LMF$'" Subject: RE: [XCON] Conference Control Date: Fri, 27 Jan 2006 18:29:04 -0500 Message-ID: <009001c62399$78c9fe30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYjXqFUItA5QWwnRsSS/PyrRfgVYgACD95QAAxu4nAAACcyQA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Just to be clear, I don't have a problem with multiple bindings as long = as the underlying data structures and operations are the same. I think having a protocol that had both a SOAP binding, and something = fast and small, especially for the typical operations, is a good thing. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Friday, January 27, 2006 6:26 PM To: Chris Boulton; Henning Schulzrinne; Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control I think Chris' proposal is very reasonable. Why is this an either-or discussion? Why not allow multiple bindings? I think it would be a = mistake to create a least common denominator approach to satisfy the constraints = of CPU/bandwidth limited devices. =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 9:28 AM To: Henning Schulzrinne; Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control Compared to implementing the logic of conference control, the = encapsulation is a tiny fraction of the work, particularly given that you can get SOAP stacks pre-packaged for almost any conceivable platform and language, = mobile or otherwise. (A SOAP client is nothing more than a bit of XML on top of HTTP, so you don't even need a stack, just an XML parser and an HTTP = client library, both of which any SIP-speaking device will need in any event.) [Chris Boulton] Agreed. Thus, I don't think this is much of a differentiator. [Chris Boulton] Either way - I am fed up of it being 'the only' differentiator. Oscar Novo (JO/LMF) wrote: > I think it=B4s quite obvious. :) > But anyway, still all the systems have to implement the SOAP protocol = > from the scratch and this is not the case of CSCP even if the systems=20 > that support the BFCP are low. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon Information contained in this e-mail and any attachments are intended = for the use of the addressee only, and may contain confidential information = of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, = please notify the sender immediately and destroy all copies of this email. = Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to = be legally binding. Thank you. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Jan 30 06:18:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3X3U-0003DZ-IT; Mon, 30 Jan 2006 06:18:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3X3Q-0003CP-Oq for xcon@megatron.ietf.org; Mon, 30 Jan 2006 06:18:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14743 for ; Mon, 30 Jan 2006 06:16:59 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3XE5-0008Sw-9I for xcon@ietf.org; Mon, 30 Jan 2006 06:29:41 -0500 Received: from rly12b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12b.srv.mailcontrol.com (MailControl) with ESMTP id k0UBILGB022700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jan 2006 11:18:23 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly12b.srv.mailcontrol.com (MailControl) id k0UBHKjX020988 for xcon@ietf.org; Mon, 30 Jan 2006 11:17:20 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly12b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k0UBHICZ020858; Mon, 30 Jan 2006 11:17:20 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [XCON] Conference Control Date: Mon, 30 Jan 2006 11:17:19 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78AA2@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjXqFUItA5QWwnRsSS/PyrRfgVYgACD95QAAxu4nAAACcyQAB9S5KQ From: "Chris Boulton" To: , "Sean Olson" , "Henning Schulzrinne" , "Oscar Novo $JO/LMF$" X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.122 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org So it looks to me like we MIGHT be getting somewhere. I'd be interested = to know what the chair's make of this current discussion and if they = think it will be achievable. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 23:29 To: 'Sean Olson'; Chris Boulton; 'Henning Schulzrinne'; 'Oscar Novo = (JO/LMF)' Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control Just to be clear, I don't have a problem with multiple bindings as long = as the underlying data structures and operations are the same. I think having a protocol that had both a SOAP binding, and something = fast and small, especially for the typical operations, is a good thing. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Friday, January 27, 2006 6:26 PM To: Chris Boulton; Henning Schulzrinne; Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control I think Chris' proposal is very reasonable. Why is this an either-or discussion? Why not allow multiple bindings? I think it would be a = mistake to create a least common denominator approach to satisfy the constraints = of CPU/bandwidth limited devices. =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 9:28 AM To: Henning Schulzrinne; Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control Compared to implementing the logic of conference control, the = encapsulation is a tiny fraction of the work, particularly given that you can get SOAP stacks pre-packaged for almost any conceivable platform and language, = mobile or otherwise. (A SOAP client is nothing more than a bit of XML on top of HTTP, so you don't even need a stack, just an XML parser and an HTTP = client library, both of which any SIP-speaking device will need in any event.) [Chris Boulton] Agreed. Thus, I don't think this is much of a differentiator. [Chris Boulton] Either way - I am fed up of it being 'the only' differentiator. Oscar Novo (JO/LMF) wrote: > I think it=B4s quite obvious. :) > But anyway, still all the systems have to implement the SOAP protocol = > from the scratch and this is not the case of CSCP even if the systems=20 > that support the BFCP are low. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon Information contained in this e-mail and any attachments are intended = for the use of the addressee only, and may contain confidential information = of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, = please notify the sender immediately and destroy all copies of this email. = Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to = be legally binding. Thank you. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Jan 30 06:33:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3XI3-0005UC-0Y; Mon, 30 Jan 2006 06:33:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3XI1-0005U3-MR for xcon@megatron.ietf.org; Mon, 30 Jan 2006 06:33:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15477 for ; Mon, 30 Jan 2006 06:32:10 -0500 (EST) Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3XSj-0000LZ-KC for xcon@ietf.org; Mon, 30 Jan 2006 06:44:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] New version of CSCP draft Date: Mon, 30 Jan 2006 13:33:20 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03215A8D@IsrExch01.israel.polycom.com> Thread-Topic: [XCON] New version of CSCP draft Thread-Index: AcYSKsUfSXsE2xgURaOr6R2I6JBtbQOlWzcAAHBFCmAAM5OUUACQI0fw From: "Even, Roni" To: "Oscar Novo $JO/LMF$" , X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d2cbbe10c97d56c753ea98882cec394 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0430760376==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0430760376== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62590.F9264955" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62590.F9264955 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oscar, =20 About =20 4. When creating a conference, how does the user learn the urn of the = templates he can use. =20 [ON] this is outside the scope of the document. Anyway, I=B4ve update = the draft telling that this is outside the scope of the document and = this information can be provided by other means, such as email or the Web. =20 I read the other drafts (COMP and CCMP) both of them define the = mechanism to learn the conference server capabilities (learn which = template are supported) and to get the templates.=20 =20 Roni =20 ________________________________ From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Friday, January 27, 2006 5:21 PM To: Even, Roni; xcon@ietf.org Subject: RE: [XCON] New version of CSCP draft =20 Hello Roni,=20 =20 Thank you very much to review the CSCP draft and provide interesting = comment. I=B4ve updated the draft according to your comments number = 2,3,5,6,7,8, and 11. In the new version you will see the changes. =20 Comments to the other numbers are inline... =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Even, Roni Sent: 26. tammikuuta 2006 16:42 To: xcon@ietf.org Subject: RE: [XCON] New version of CSCP draft Hi, I read the draft and would like to give the following feedback that = includes questions and comments. =20 1. The document is using the conference event package after the = conference creation in order to get the elements IDs. My understanding = so far is that a UA subscribes to a conference that is running now and = not to one that is created and may run later. I see this as a major = issue since the whole solution is based on it. It is not only issue of = when you can subscribe to a conference state but also about extending = the conference event package to include all the elements and attributes = that are needed to create conferences which are not there. =20 [ON] But the current conference event package represents just the state = of the conference. Do you think is good idea to extend the conference = event package to support more than the state? Maybe,the CSCP protocol = should especify a mechanism to query the capabilities of the system. = Now, the CSCP protocol only allow to retrieve the attribute values. What = do you think? =20 4. When creating a conference, how does the user learn the urn of = the templates he can use. =20 [ON] this is outside the scope of the document. Anyway, I=B4ve update = the draft telling that this is outside the scope of the document and = this information can be provided by other means, such as email or the Web. =20 =20 9. In the example in section 11.1 the addConferenceAck message = returns Conference ID: 000. Shouldn't it be the same as the ELEMENT-ID.=20 =20 [ON]I just try to keep the same behaviour in the addConferenceAck = message than in the other messages. Normally, when a server receives a = CSCP or BFCP message, it copies in the response the same Conference-ID = attribute than the one in the message receives. =20 10. I noticed that section 12 talks about correlation with the = conference event package. Just note that the dial-out-list in the = example of section 11.3 is not a child element of users. There is no = dial-out list in the event package, since this is not a state. There is = information inside the endpoint element if this was a dial out or dial = in call.=20 =20 [ON] The dial-out-list is defined in the "Common Conference Information = Data Model for Centralized Conferencing (XCON)" as an element of users. = The dial-out-list is not defined in the event package because the event = package only shows the state of the conference.=20 =20 =20 =20 Roni Even ------_=_NextPart_001_01C62590.F9264955 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Oscar,

About

=

4. When creating a conference, how does the user learn the urn of the templates = he can use.

[ON] this is outside the = scope of the document. Anyway, I=B4ve update the draft telling = that this is outside the scope of the document and this information can be = provided
   by other means, such as email or the = Web.

I read the other drafts (COMP and = CCMP) both of them define the mechanism to learn the conference server = capabilities (learn which template are supported) and to get the templates. =

Roni

From: Oscar = Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Friday, January 27, = 2006 5:21 PM
To: Even, Roni; = xcon@ietf.org
Subject: RE: [XCON] New = version of CSCP draft

Hello Roni, =

Thank you very much to review = the CSCP draft and provide interesting comment. I=B4ve updated the = draft according to your comments number 2,3,5,6,7,8, and 11. In the new = version you will see the changes.

Comments to the other numbers are inline...

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Even, Roni
Sent: 26. tammikuuta 2006 = 16:42
To: xcon@ietf.org
Subject: RE: [XCON] New = version of CSCP draft

Hi,

I read the draft and would like to = give the following feedback that includes questions and = comments.

1.       = The document is using the conference event package after the conference creation in order to get the elements IDs. My understanding = so far is that a UA subscribes to a conference that is running now and not to = one that is created and may run later. I see this as a major issue since = the whole solution is based on it. It is not only issue of when you can subscribe = to a conference state but also about extending the conference event package = to include all the elements and attributes that are needed to create conferences = which are not there.

=

[ON] But the current conference event package represents just the state of the conference. = Do you think is good idea to extend the conference event package to support = more than the state? Maybe,the CSCP protocol should especify a mechanism to query = the capabilities of the system. Now, the CSCP protocol only allow to = retrieve the attribute values. What do you think?

=

4.<= font size=3D1 color=3Dnavy>      = When creating a conference, how does the = user learn the urn of the templates he can use.

[ON] this is outside the scope of = the document. Anyway, I=B4ve update the draft telling that this is = outside the scope of the document and this information can be provided
   by other means, such as email or the = Web.

9.     &nb= sp; In the example in section 11.1 the addConferenceAck message returns Conference ID: 000. Shouldn’t it be the same as = the ELEMENT-ID.

[ON]I just try to keep the same = behaviour in the addConferenceAck message than in the other = messages. Normally, when a server receives a CSCP or BFCP message, it copies in = the response the same Conference-ID attribute than the one in the message = receives.

10.   I noticed that section 12 talks about correlation with = the conference event package. Just note that the dial-out-list in the = example of section 11.3 is not a child element of users. There is no dial-out list = in the event package, since this is not a state. There is information inside = the endpoint element if this was a dial out or dial in = call.

[ON] The dial-out-list is defined in the "Common Conference Information Data Model for Centralized Conferencing = (XCON)" as an element of users. The dial-out-list is not defined in the event = package because the event package only shows the state of the = conference.

Roni = Even

------_=_NextPart_001_01C62590.F9264955-- --===============0430760376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0430760376==-- From xcon-bounces@ietf.org Mon Jan 30 06:51:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3XZ9-0008PV-8h; Mon, 30 Jan 2006 06:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3XZ6-0008LZ-K1 for xcon@megatron.ietf.org; Mon, 30 Jan 2006 06:51:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16446 for ; Mon, 30 Jan 2006 06:49:41 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Xjc-0000ne-E0 for xcon@ietf.org; Mon, 30 Jan 2006 07:02:23 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 56357171; Mon, 30 Jan 2006 12:51:01 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 12:51:00 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 12:51:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] New version of CSCP draft Date: Mon, 30 Jan 2006 12:50:58 +0100 Message-ID: Thread-Topic: [XCON] New version of CSCP draft Thread-Index: AcYSKsUfSXsE2xgURaOr6R2I6JBtbQOlWzcAAHBFCmAAM5OUUACQI0fwAACyTwA= From: "Oscar Novo $JO/LMF$" To: "Even, Roni" , X-OriginalArrivalTime: 30 Jan 2006 11:51:00.0691 (UTC) FILETIME=[70A4DA30:01C62593] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 04b84659b2acb599bee006e63124a606 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1022665706==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1022665706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62593.1413E54A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62593.1413E54A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 So, if people think it is needed. We can add an operation "GetTemplate" = to the CSCP protocol. =20 Oscar ________________________________ From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: 30. tammikuuta 2006 13:33 To: Oscar Novo (JO/LMF); xcon@ietf.org Subject: RE: [XCON] New version of CSCP draft Oscar, =20 About =20 4. When creating a conference, how does the user learn the urn of the = templates he can use. =20 [ON] this is outside the scope of the document. Anyway, I=B4ve update = the draft telling that this is outside the scope of the document and = this information can be provided by other means, such as email or the Web. =20 I read the other drafts (COMP and CCMP) both of them define the = mechanism to learn the conference server capabilities (learn which = template are supported) and to get the templates.=20 =20 Roni =20 ________________________________ From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Friday, January 27, 2006 5:21 PM To: Even, Roni; xcon@ietf.org Subject: RE: [XCON] New version of CSCP draft =20 Hello Roni,=20 =20 Thank you very much to review the CSCP draft and provide interesting = comment. I=B4ve updated the draft according to your comments number = 2,3,5,6,7,8, and 11. In the new version you will see the changes. =20 Comments to the other numbers are inline... =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Even, Roni Sent: 26. tammikuuta 2006 16:42 To: xcon@ietf.org Subject: RE: [XCON] New version of CSCP draft Hi, I read the draft and would like to give the following feedback that = includes questions and comments. =20 1. The document is using the conference event package after the = conference creation in order to get the elements IDs. My understanding = so far is that a UA subscribes to a conference that is running now and = not to one that is created and may run later. I see this as a major = issue since the whole solution is based on it. It is not only issue of = when you can subscribe to a conference state but also about extending = the conference event package to include all the elements and attributes = that are needed to create conferences which are not there. =20 [ON] But the current conference event package represents just the state = of the conference. Do you think is good idea to extend the conference = event package to support more than the state? Maybe,the CSCP protocol = should especify a mechanism to query the capabilities of the system. = Now, the CSCP protocol only allow to retrieve the attribute values. What = do you think? =20 4. When creating a conference, how does the user learn the urn of = the templates he can use. =20 [ON] this is outside the scope of the document. Anyway, I=B4ve update = the draft telling that this is outside the scope of the document and = this information can be provided by other means, such as email or the Web. =20 =20 9. In the example in section 11.1 the addConferenceAck message = returns Conference ID: 000. Shouldn't it be the same as the ELEMENT-ID.=20 =20 [ON]I just try to keep the same behaviour in the addConferenceAck = message than in the other messages. Normally, when a server receives a = CSCP or BFCP message, it copies in the response the same Conference-ID = attribute than the one in the message receives. =20 10. I noticed that section 12 talks about correlation with the = conference event package. Just note that the dial-out-list in the = example of section 11.3 is not a child element of users. There is no = dial-out list in the event package, since this is not a state. There is = information inside the endpoint element if this was a dial out or dial = in call.=20 =20 [ON] The dial-out-list is defined in the "Common Conference Information = Data Model for Centralized Conferencing (XCON)" as an element of users. = The dial-out-list is not defined in the event package because the event = package only shows the state of the conference.=20 =20 =20 =20 Roni Even ------_=_NextPart_001_01C62593.1413E54A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

So, if=20 people think it is needed. We can add an operation "GetTemplate" to the = CSCP=20 protocol.

Oscar

From: Even, Roni=20 [mailto:roni.even@polycom.co.il]
Sent: 30. tammikuuta 2006=20 13:33
To: Oscar Novo (JO/LMF); = xcon@ietf.org
Subject: RE:=20 [XCON] New version of CSCP draft

Oscar,

About

4. When=20 creating a conference, how does the user learn the urn of the templates = he can=20 use.

[ON] = this is=20 outside the scope of the document. Anyway, I=B4ve update the draft = telling=20 that this is outside the scope of the document and this = information=20 can be provided
   by other means, such as email or the=20 Web.

I read the = other drafts=20 (COMP and CCMP) both of them define the mechanism to learn the = conference server=20 capabilities (learn which template are supported) and to get the = templates.=20

Roni

From: Oscar=20 Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Friday, January 27, 2006 = 5:21=20 PM
To: Even, Roni;=20 xcon@ietf.org
Subject: RE:=20 [XCON] New version of CSCP draft

Hello Roni,=20

Thank you = very=20 much to review the CSCP draft and provide interesting comment. = I=B4ve=20 updated the draft according to your comments number 2,3,5,6,7,8, = and=20 11. = In=20 the new version you will see the = changes.

Comments to = the other=20 numbers are inline...

From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Even, = Roni
Sent: 26. tammikuuta 2006 = 16:42
To: xcon@ietf.org
Subject: RE: [XCON] New version = of CSCP=20 draft

Hi,

I read the = draft and=20 would like to give the following feedback that includes questions and=20 comments.

1.      =20 The document = is using=20 the conference event package after the conference creation in order to = get the=20 elements IDs. My understanding so far is that a UA subscribes to a = conference=20 that is running now and not to one that is created and may run later. = I=20 see this as a major issue since the whole solution is based on it. It is = not=20 only issue of when you can subscribe to a conference state but also = about=20 extending the conference event package to include all the elements and=20 attributes that are needed to create conferences which are not=20 there.

[ON] But=20 the current conference event package represents just the state of the=20 conference. = Do you=20 think is good idea to extend the conference event package to support = more than=20 the state? Maybe,the CSCP protocol should especify a mechanism to query = the=20 capabilities of the system. Now, the CSCP protocol only allow to = retrieve the=20 attribute values. What do you think?

4.      =20 When creating = a=20 conference, how does the user learn the urn of the templates he can=20 use.

[ON] this is = outside=20 the scope of the document. Anyway, I=B4ve update the draft telling=20 that this is outside the scope of the document and this = information=20 can be provided
   by other means, such as email or the=20 Web.

9.      =20 In the = example in=20 section 11.1 the addConferenceAck message returns Conference ID: 000. = Shouldn=92t=20 it be the same as the ELEMENT-ID.

[ON]I just = try to keep=20 the same behaviour in the addConferenceAck message than = in the=20 other messages. Normally, when a server receives a CSCP or BFCP message, = it=20 copies in the response the same Conference-ID attribute than the one in = the=20 message receives.

10.  =20 I noticed = that=20 section 12 talks about correlation with the conference event package. = Just note=20 that the dial-out-list in the example of section 11.3 is not a child = element of=20 users. There is no dial-out list in the event package, since this is not = a=20 state. There is information inside the endpoint element if this was a = dial out=20 or dial in call.

[ON] = The=20 dial-out-list is defined in the "Common Conference Information Data = Model for=20 Centralized Conferencing (XCON)" as an element of users. The = dial-out-list is=20 not defined in the event package because the event package only shows = the state=20 of the conference.

Roni=20 Even
------_=_NextPart_001_01C62593.1413E54A-- --===============1022665706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1022665706==-- From xcon-bounces@ietf.org Mon Jan 30 11:39:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3c3e-0000cs-0M; Mon, 30 Jan 2006 11:39:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3c3c-0000bG-Mx for xcon@megatron.ietf.org; Mon, 30 Jan 2006 11:39:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05735 for ; Mon, 30 Jan 2006 11:37:22 -0500 (EST) Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3cE9-0001Dv-FB for xcon@ietf.org; Mon, 30 Jan 2006 11:50:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Date: Mon, 30 Jan 2006 18:38:36 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03215BBA@IsrExch01.israel.polycom.com> Thread-Topic: [XCON] Conference Control Thread-Index: AcYjKJ/h2PuP4y/ATgyoxJFxW24YJQAHVOwgAANiCJAAANmeIAAAT+tAAJjIO8A= From: "Even, Roni" To: "Chris Boulton" , "Oscar Novo $JO/LMF$" , , X-Spam-Score: 0.3 (/) X-Scan-Signature: d7d3f294c642eb492c2d44336474db48 Cc: ajohnston@tello.com, Adam Roach X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1101757405==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1101757405== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C625BB.9E2123F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C625BB.9E2123F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 This brings up an interesting question, is floor control needed for conferencing, probably yes in some cases. So this may mean two separate control channels. Maybe it will make sense, once we decide on the protocol/s to define if we can tunnel BFCP through this protocol. =20 Roni Even =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:43 PM To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control =20 =20 =20 Chris, =20 Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory. =20 [Chris Boulton] What proof is this comments based on? =20 So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch. =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: 27. tammikuuta 2006 17:13 To: br@brianrosen.net; xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: RE: [XCON] Conference Control Hi Brian, =20 Clarification in-line. =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 January 2006 14:27 To: Chris Boulton; xcon@ietf.org Cc: ajohnston@tello.com; 'Adam Roach' Subject: RE: [XCON] Conference Control =20 I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different. I'm not sure that would be particularly interesting to you. =20 Also, could you clarify your statements on CSCP? What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden". I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden. I think if you implement BFCP then CSCP is relatively less work from there.=20 =20 [Chris Boulton] The XCON Framework reads: Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users. =20 So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory. So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated web interface is preferred. Chris. =20 =20 Brian =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Friday, January 27, 2006 5:01 AM To: xcon@ietf.org Cc: ajohnston@tello.com; Adam Roach Subject: [XCON] Conference Control =20 Hi All, =20 Just wanted to generate some discussion relating to the recent Conference Control submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas. =20 =20 While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be providing questions and feedback in individual mails. This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important. As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on. This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?' As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice. From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients. =20 It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset. I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures. =20 I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months. =20 Best Regards, =20 Chris Boulton. =20 Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you=20 ------_=_NextPart_001_01C625BB.9E2123F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=

This brings up = an interesting question, is floor control needed for conferencing, probably yes in some = cases. So this may mean two separate control channels. Maybe it will make = sense, once we decide on the protocol/s to define if we can tunnel BFCP through this = protocol.

=

Roni = Even

=

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Friday, January 27, = 2006 5:43 PM
To: Oscar Novo (JO/LMF); br@brianrosen.net; xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

Chris,

Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this comments based = on?

So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from = scratch.

Oscar

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: 27. tammikuuta 2006 = 17:13
To: br@brianrosen.net; = xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: RE: [XCON] = Conference Control

Hi Brian,

Clarification in-line.

Chris.

-----Original = Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: 27 January 2006 = 14:27
To: Chris Boulton; = xcon@ietf.org
Cc: ajohnston@tello.com; = 'Adam Roach'
Subject: RE: [XCON] = Conference Control

I’m not opposed to having two bindings to the same interface, but I would = not want to see two interfaces. That means the models, data structures, operations, errors, etc would have to be identical, with only transport = being different. I’m not sure that would be particularly = interesting to you.

Also, could you clarify your statements on CSCP? What you said was = “it may be likely, as it is not mandatory, that BFCP be implemented in the = solution and so developing support for something like CSCP would be seen as a burden”. I can’t figure out if you WILL implement = BFCP, and thus CSCP is easy, or you won’t implement BFCP because it’s = not mandatory and thus CSCP would be a burden. I think if you = implement BFCP then CSCP is relatively less work from there.

[Chris Boulton] The XCON Framework reads:

Floor control is not a mandatory mechanism = for a conferencing system implementation but provides advanced media = input control features for conference = users.

So the point I was trying = to convey was that BFCP, as it stands in the Framework is not mandatory. = So for an element wanting to use just CSCP would have to develop from scratch. In this scenario, just having to expose a WSDL initiated = web interface is preferred.

Chris.

Brian

From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Chris Boulton
Sent: Friday, January 27, = 2006 5:01 AM
To: xcon@ietf.org
Cc: ajohnston@tello.com; = Adam Roach
Subject: [XCON] = Conference Control

Hi = All,

Just wanted to = generate some discussion relating to the recent Conference Control = submissions. I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.

While I = realise that the thoughts conveyed in this mail are a little controversial, I thought I = would poke my head up into the firing line in attempt to stimulate some discussion. I have reviewed all of the proposals and will be = providing questions and feedback in individual mails. This mail is an = attempt to discuss some architectural decisions that I personally feel are equally = as important. As some of you may already know, I am a supporter of = the SOAP proposals (Henning, myself and Mary) that are currently being worked = on. This led me to realise that my preference was being swayed (purely = selfish :-) by ‘who exactly will be a conference client manipulating = Conference Objects?’ As an application server vendor who’s = product very much utilises web services. SOAP seems the obvious choice. From a = handset vendor I can also see that proposals such as CCCP and CSCP are more appealing. As an application server offering conferencing services = using web services it may be likely, as it is not mandatory, that BFCP be = implemented in the solution and so developing support for something like CSCP would = be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our = clients.

It is for = these reasons that I was pondering the prospect of XCON allowing both a handset = friendly interface such as CSCP and a SOAP interface for web services where the = client might well be another application and not a handset. I realise = that having two interfaces is not ideal, but as long as we are careful in our = rules on minimal implementation and ability to advertise capabilities to a = Conference Client I personally feel that this is the best solution to make XCON = appealing to a wide variety of architectures.

I’m = going to duck now and wait for incoming bullets but on a serious note I strongly = appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming = months.

Best = Regards,

Chris = Boulton.

Information contained in = this e-mail and any attachments are intended for the use of the addressee = only, and may contain confidential information of Ubiquity Software Corporation. = All unauthorized use, disclosure or distribution is strictly = prohibited. If you are not the addressee, please notify the sender immediately and = destroy all copies of this email. Unless otherwise expressly agreed in writing = signed by an officer of Ubiquity Software Corporation, nothing in this = communication shall be deemed to be legally binding. Thank-you =

------_=_NextPart_001_01C625BB.9E2123F0-- --===============1101757405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1101757405==-- From xcon-bounces@ietf.org Tue Jan 31 03:24:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3qo5-0000XS-Nu; Tue, 31 Jan 2006 03:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3qo3-0000VQ-Kw for xcon@megatron.ietf.org; Tue, 31 Jan 2006 03:24:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24417 for ; Tue, 31 Jan 2006 03:22:08 -0500 (EST) Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3qyb-0001cB-MP for xcon@ietf.org; Tue, 31 Jan 2006 03:35:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2006 10:23:33 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03215CA8@IsrExch01.israel.polycom.com> Thread-Topic: General comments on conference control Thread-Index: AcYjXqFUItA5QWwnRsSS/PyrRfgVYgACD95QAAxu4nAAACcyQAB9S5KQACu0RBA= From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Subject: [XCON] General comments on conference control X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0826458098==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0826458098== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6263F.A00F83AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6263F.A00F83AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 I read the CSCP, COMP and CCMP drafts. This email presents general issues that in my view should be addressed in the proposed solution (or solutions). The drafts address part of those issues. I know that some of the issues may be addressed after the protocol is selected. =20 1. The solution need to specify how the client application finds which templates are available and how to get a specific template for the required conference. 2. How to get conference status. The documents refer to the conference event package and to the xcon-common-data-model for the conference data structure. It is not clear how to follow changes in the data. Is it based on event notification or on the conference control protocol. If it is a mixture, how does it work. 3. The documents suggest subscribing to the conference event package. At which stage of the conference can you subscribe to its state. For example, using the conference control protocol, the client defines a conference that will be scheduled next week. Can the client subscribe to the conference URI it receives. 4. Floor control in conference, is it a separate protocol using a separate channel, can we use BFCP tunneled in the selected protocol if it is not CSCP =20 Thanks Roni Even=20 ------_=_NextPart_001_01C6263F.A00F83AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read the CSCP, COMP and CCMP drafts. This email presents = general issues that in my view should be addressed in the proposed solution (or solutions). The drafts address part of those issues. I know that some of = the issues may be addressed after the protocol is = selected.

1.     = The solution need to specify how the client application finds = which templates are available and how to get a specific template for the = required conference.

2.     = How to get conference status. The documents refer to the = conference event package and to the xcon-common-data-model for the conference data structure. It is not clear how to follow changes in the data. Is it = based on event notification or on the conference control protocol. If it is a = mixture, how does it work.

3.     = The documents suggest subscribing to the conference event = package. At which stage of the conference can you subscribe to its state. For = example, using the conference control protocol, the client defines a conference = that will be scheduled next week. Can the client subscribe to the conference = URI it receives.

4.     = Floor control in conference, is it a separate protocol using a = separate channel, can we use BFCP tunneled in the selected protocol if it is not = CSCP

Thanks

Roni Even

------_=_NextPart_001_01C6263F.A00F83AF-- --===============0826458098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0826458098==--