From xcon-bounces@ietf.org Wed Feb 01 02:54:58 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 1F4CpO-0002yZ-Oc; Wed, 01 Feb 2006 02:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4CpJ-0002vk-49 for xcon@megatron.ietf.org; Wed, 01 Feb 2006 02:54:55 -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 CAA19866 for ; Wed, 1 Feb 2006 02:53:16 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4D0R-0002Ym-BY for xcon@ietf.org; Wed, 01 Feb 2006 03:06:23 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6392F4F0001; Wed, 1 Feb 2006 08:54:51 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 08:54:50 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 08:54:50 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Feb 2006 08:54:49 +0100 Message-ID: Thread-Topic: =?iso-8859-1?Q?Chair=B4s_opinion_=3A=29?= Thread-Index: AcYjXqFUItA5QWwnRsSS/PyrRfgVYgACD95QAAxu4nAAACcyQAB9S5KQAF1R4xA= From: "Oscar Novo \(JO/LMF\)" To: "Chris Boulton" , , X-OriginalArrivalTime: 01 Feb 2006 07:54:50.0681 (UTC) FILETIME=[C77C6A90:01C62704] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org Subject: [XCON] =?iso-8859-1?q?Chair=B4s_opinion_=3A=29?= 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 Yes, I think is good idea to know the chair's opinion in this = discussion. It would be useful for everybody. :) Oscar -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: 30. tammikuuta 2006 13:17 To: br@brianrosen.net; Sean Olson; Henning Schulzrinne; Oscar Novo = (JO/LMF) Cc: xcon@ietf.org Subject: RE: [XCON] Conference Control 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] 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=20 > 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 Wed Feb 01 04:26:42 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 1F4EGA-0002oL-Mp; Wed, 01 Feb 2006 04:26:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EG8-0002no-LV for xcon@megatron.ietf.org; Wed, 01 Feb 2006 04:26: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 EAA25810 for ; Wed, 1 Feb 2006 04:24:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ERA-0005nR-RC for xcon@ietf.org; Wed, 01 Feb 2006 04:38:06 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 01 Feb 2006 01:26:24 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k119QNWF016878; Wed, 1 Feb 2006 01:26:23 -0800 (PST) Received: from 10.21.124.55 ([10.21.124.55]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Feb 2006 09:26:22 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Feb 2006 01:26:39 -0800 Subject: Re: [XCON] Conference Control From: Cullen Jennings To: Henning Schulzrinne , Chris Boulton Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYnEZqz2VLP85MEEdq9lAARJEEJ/A== In-Reply-To: <43DA4377.5020900@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ajohnston@tello.com, 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 On 1/27/06 7:59 AM, "Henning Schulzrinne" wrote: > Let's not trot out the same non-relevant arguments each time. Right - we had this argument and the conclusion was that BFCP was needed and that bandwidth was an issue. I don't even know if I think we made the right decision or not - but we did make a decision on the topic. I suspect that if you review the arguments that let to selection of BFCP, you will come to the conclusion that the same arguments apply to "mute participant". It was less about the actual bandwidth used and more about the latency that large messages (something like over 160 bytes) would introduce. I do think we could split the arguments on couple exists. One is encoding of XML or SOAP or Binary. Another axis's is what are the operations. I suspect the operations are actually the more contentious issue. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Feb 01 12:19:07 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 1F4LdL-0000sG-F2; Wed, 01 Feb 2006 12:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4LdI-0000o5-Tv for xcon@megatron.ietf.org; Wed, 01 Feb 2006 12:19:06 -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 MAA16461 for ; Wed, 1 Feb 2006 12:17:28 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4LoU-0005VH-UE for xcon@ietf.org; Wed, 01 Feb 2006 12:30:40 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 1 Feb 2006 09:18:51 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 09:18:51 -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); Wed, 1 Feb 2006 09:18:50 -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); Wed, 1 Feb 2006 09:18:50 -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: [XCON] Conference Control Date: Wed, 1 Feb 2006 09:18:49 -0800 Message-ID: In-Reply-To: Thread-Topic: [XCON] Conference Control thread-index: AcYnEZqz2VLP85MEEdq9lAARJEEJ/AAQZhig From: "Sean Olson" To: "Cullen Jennings" , "Henning Schulzrinne" , "Chris Boulton" X-OriginalArrivalTime: 01 Feb 2006 17:18:50.0280 (UTC) FILETIME=[91757280:01C62753] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ajohnston@tello.com, 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 Just one correction I would like to make.=20 Encoding is XML or Binary or X ... Transport/Binding is SOAP or X ... I do agree we need to review the operations with more scrutiny perhaps than this encoding discussion. I do not however agree that a decision to use a binary encoding for floor control necessarily means we should generally be constrained to use a binary encoding for conference control.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, February 01, 2006 1:27 AM To: Henning Schulzrinne; Chris Boulton Cc: ajohnston@tello.com; Adam Roach; XCON-IETF Subject: Re: [XCON] Conference Control On 1/27/06 7:59 AM, "Henning Schulzrinne" wrote: > Let's not trot out the same non-relevant arguments each time. Right - we had this argument and the conclusion was that BFCP was needed and that bandwidth was an issue. I don't even know if I think we made the right decision or not - but we did make a decision on the topic. I suspect that if you review the arguments that let to selection of BFCP, you will come to the conclusion that the same arguments apply to "mute participant". It was less about the actual bandwidth used and more about the latency that large messages (something like over 160 bytes) would introduce. I do think we could split the arguments on couple exists. One is encoding of XML or SOAP or Binary. Another axis's is what are the operations. I suspect the operations are actually the more contentious issue. _______________________________________________ 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 Wed Feb 01 18:16:11 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 1F4RCt-0004O3-MO; Wed, 01 Feb 2006 18:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4RCr-0004KK-Mw for xcon@megatron.ietf.org; Wed, 01 Feb 2006 18:16:09 -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 SAA25684 for ; Wed, 1 Feb 2006 18:14:33 -0500 (EST) Received: from dsl027-191-186.sfo1.dsl.speakeasy.net ([216.27.191.186] helo=email.tello.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4RO5-0005Fd-Br for xcon@ietf.org; Wed, 01 Feb 2006 18:27:48 -0500 Received: from [10.59.1.72] (unknown [216.254.21.35]) by email.tello.com (Postfix) with ESMTP id 1675AA00DB; Wed, 1 Feb 2006 15:14:03 -0800 (PST) Message-ID: <43E14117.3090202@tello.com> Date: Wed, 01 Feb 2006 15:15:35 -0800 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] =?ISO-8859-1?Q?Chair=B4s_opinion_=3A=29?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-tello-MailScanner-Information: Please contact the ISP for more information X-tello-MailScanner: Found to be clean X-tello-MailScanner-From: ajohnston@tello.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , adam@nostrum.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 (as chair) I am encouraged by the level and direction of this discussion - lets=20 keep it up, everyone. Having multiple transports is possible, of course. Interop should be=20 possible by requiring servers to support both transports while clients=20 can support either. However, I still think we need to decide the fundamental question of=20 whether conference control is about data manipulation alone, data=20 manipulation plus commands, or purely command based. I would like to=20 see this addressed. The working group consensus on this will validate=20 whether multiple transports or bindings will even work. Thanks, Alan Johnston co-chair Oscar Novo (JO/LMF) wrote: >Yes, I think is good idea to know the chair's opinion in this discussion= . It would be useful for everybody. :) > >Oscar > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 >Sent: 30. tammikuuta 2006 13:17 >To: br@brianrosen.net; Sean Olson; Henning Schulzrinne; Oscar Novo (JO/L= MF) >Cc: xcon@ietf.org >Subject: RE: [XCON] Conference Control > >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 thi= nk it will be achievable. > >Chris. > > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >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 fa= st 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 dis= cussion? Why not allow multiple bindings? I think it would be a mistake t= o create a least common denominator approach to satisfy the constraints o= f 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 encapsulat= ion is a tiny fraction of the work, particularly given that you can get S= OAP 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 H= TTP client library, both of which any SIP-speaking device will need in an= y 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: > =20 > >>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 fo= r the use of the addressee only, and may contain confidential information= of Ubiquity Software Corporation. All unauthorized use, disclosure or d= istribution is strictly prohibited. If you are not the addressee, please= notify the sender immediately and destroy all copies of this email. Unl= ess otherwise expressly agreed in writing signed by an officer of Ubiquit= y 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 > > > =20 > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Feb 01 23:48: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 1F4WOH-0006Pe-Sa; Wed, 01 Feb 2006 23:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4WOF-0006JP-4K for xcon@megatron.ietf.org; Wed, 01 Feb 2006 23:48:15 -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 XAA25223 for ; Wed, 1 Feb 2006 23:46:29 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4WZQ-0001cz-Hp for xcon@ietf.org; Wed, 01 Feb 2006 23:59:48 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2006 20:47:58 -0800 X-IronPort-AV: i="4.01,245,1136188800"; d="scan'208"; a="1772645320:sNHT33214044" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k124lvQJ010974; Wed, 1 Feb 2006 20:47:57 -0800 (PST) Received: from 10.82.210.162 ([10.82.210.162]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 04:47:57 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Feb 2006 20:48:13 -0800 Subject: Re: [XCON] Conference Control From: Cullen Jennings To: Sean Olson , Henning Schulzrinne , Chris Boulton Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYnEZqz2VLP85MEEdq9lAARJEEJ/AAQZhigABgrH5w= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ajohnston@tello.com, 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 On 2/1/06 9:18 AM, "Sean Olson" wrote: > I do not however agree that a decision to > use a binary encoding for floor control necessarily means we should > generally be constrained to use a binary encoding for conference > control. I certainly have mixed feelings on this myself. I do think that it makes a fairly strong argument that we need to at least have one protocol that supports the functionality and is usable in the same environment that BFCP was designed for. That does not stop us from having a second protocol with the same functionality that does not work in the environment BFCP was designed for. I'm pretty sure that I did point this all out back when we approved BFCP that selecting one of the key protocols before having even a rough idea on the architecture was going to constrain our options later and that if we were accepting the BFCP requirements, well we had to accept them for enough to do xcon conferences on that sort of device, and that would imply similar constraints on the other protocols. No one seemed to have a problem with this back when we did BFCP. Ironically, I was the one of the only people that had any reservations about BFCP. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Feb 01 23:53: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 1F4WTU-00018p-0P; Wed, 01 Feb 2006 23:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4WTP-00017j-NC for xcon@megatron.ietf.org; Wed, 01 Feb 2006 23:53: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 XAA25506 for ; Wed, 1 Feb 2006 23:51:53 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Wed-0001uN-CI for xcon@ietf.org; Thu, 02 Feb 2006 00:05:12 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2006 20:53:21 -0800 X-IronPort-AV: i="4.01,245,1136188800"; d="scan'208"; a="253057604:sNHT30788900" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k124rJQJ011936; Wed, 1 Feb 2006 20:53:19 -0800 (PST) Received: from 10.82.210.162 ([10.82.210.162]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 04:53:19 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Feb 2006 20:53:35 -0800 Subject: Re: [XCON] Chair=?ISO-8859-1?B?tA==?=s opinion :) From: Cullen Jennings To: Alan Johnston , "Oscar Novo (JO/LMF)" Message-ID: Thread-Topic: [XCON] Chair=?ISO-8859-1?B?tA==?=s opinion :) Thread-Index: AcYntJ983lTYbpOnEdqigAARJEEJ/A== In-Reply-To: <43E14117.3090202@tello.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Chris Boulton , adam@nostrum.com, 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 On 2/1/06 3:15 PM, "Alan Johnston" wrote: > However, I still think we need to decide the fundamental question of > whether conference control is about data manipulation alone, data > manipulation plus commands, or purely command based. I would like to > see this addressed. The working group consensus on this will validate > whether multiple transports or bindings will even work. I think this terminology heavily bias the decision but continuing on with it ... Given how we have data in the server that is defined after the client is compiled, I think there *has* to be some of what you call data manipulation (though there could be toher things too). If someone disagrees with this, then I am probably misunderstanding the terms. I also think that with any command, you may have situations where you have to set data at the same point. And I don't want two phase commits because they are two hard to implement so the data needs to "go along" with the command. If you accept we have to have the above, I rather have a small command set than a large one because I think a small set will do. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Feb 02 07:08: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 1F4dGK-0001DD-DS; Thu, 02 Feb 2006 07:08:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4dGG-0001BE-Om for xcon@megatron.ietf.org; Thu, 02 Feb 2006 07:08:31 -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 HAA26234 for ; Thu, 2 Feb 2006 07:06:42 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4dRQ-00008u-NU for xcon@ietf.org; Thu, 02 Feb 2006 07:20:04 -0500 Received: from rly01b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly01b.srv.mailcontrol.com (MailControl) with ESMTP id k12C81Nm009608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 12:08:01 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly01b.srv.mailcontrol.com (MailControl) id k12C7oQ9009288 for xcon@ietf.org; Thu, 2 Feb 2006 12:07:50 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly01b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k12C7jxg009051; Thu, 02 Feb 2006 12:07:50 +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: =?iso-8859-1?Q?RE=3A_=5BXCON=5D_Chair=B4s_opinion_=3A=29?= Date: Thu, 2 Feb 2006 12:02:53 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78AD4@gbnewp0758m.eu.ubiquity.net> Thread-Topic: =?iso-8859-1?Q?=5BXCON=5D_Chair=B4s_opinion_=3A=29?= Thread-Index: AcYntJ983lTYbpOnEdqigAARJEEJ/AAO6gKg From: "Chris Boulton" To: "Cullen Jennings" , "Alan Johnston" , "Oscar Novo \(JO/LMF\)" X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.66.1.111 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: adam@nostrum.com, 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 > However, I still think we need to decide the fundamental question of > whether conference control is about data manipulation alone, data > manipulation plus commands, or purely command based. I would like to > see this addressed. The working group consensus on this will validate > whether multiple transports or bindings will even work. I think this terminology heavily bias the decision but continuing on with it ... Given how we have data in the server that is defined after the client is compiled, I think there *has* to be some of what you call data manipulation (though there could be toher things too). If someone disagrees with this, then I am probably misunderstanding the terms. [Chris Boulton] Agreed. I also think that with any command, you may have situations where you have to set data at the same point. And I don't want two phase commits because they are two hard to implement so the data needs to "go along" with the command.=20 [Chris Boulton] Agreed. If you accept we have to have the above, I rather have a small command set than a large one because I think a small set will do. [Chris Boulton] Again, Agreed. Command set certainly doesn't need to be la= rge.=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. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Feb 02 13:20: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 1F4j46-0001HT-ES; Thu, 02 Feb 2006 13:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4j42-0001GE-Vl for xcon@megatron.ietf.org; Thu, 02 Feb 2006 13:20:15 -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 NAA26221 for ; Thu, 2 Feb 2006 13:18:37 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4jFQ-0005kv-98 for xcon@ietf.org; Thu, 02 Feb 2006 13:32:02 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 2 Feb 2006 10:19:59 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 10:19:58 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 10:19:58 -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); Thu, 2 Feb 2006 10:19:58 -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: =?iso-8859-1?Q?RE=3A_=5BXCON=5D_Chair=B4s_opinion_=3A=29?= Date: Thu, 2 Feb 2006 10:19:55 -0800 Message-ID: In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78AD4@gbnewp0758m.eu.ubiquity.net> Thread-Topic: =?iso-8859-1?Q?=5BXCON=5D_Chair=B4s_opinion_=3A=29?= thread-index: AcYntJ983lTYbpOnEdqigAARJEEJ/AAO6gKgAA0yVxA= From: "Sean Olson" To: "Chris Boulton" , "Cullen Jennings" , "Alan Johnston" , "Oscar Novo \(JO/LMF\)" X-OriginalArrivalTime: 02 Feb 2006 18:19:58.0001 (UTC) FILETIME=[46010210:01C62825] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: adam@nostrum.com, 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 Yeah, not sure I understand the terminology either ... What is the = purpose of the command if it does not involve some amount of data = manipulation? The command set doesn't need to be large, but hopefully it = is not just 4 commands (get, set, create, delete) ;-) -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Chris Boulton Sent: Thursday, February 02, 2006 4:03 AM To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF) Cc: adam@nostrum.com; XCON-IETF Subject: RE: [XCON] Chair=B4s opinion :) > However, I still think we need to decide the fundamental question of=20 > whether conference control is about data manipulation alone, data=20 > manipulation plus commands, or purely command based. I would like to=20 > see this addressed. The working group consensus on this will validate = > whether multiple transports or bindings will even work. I think this terminology heavily bias the decision but continuing on = with it ... Given how we have data in the server that is defined after the client is = compiled, I think there *has* to be some of what you call data = manipulation (though there could be toher things too). If someone = disagrees with this, then I am probably misunderstanding the terms. [Chris Boulton] Agreed. I also think that with any command, you may have situations where you = have to set data at the same point. And I don't want two phase commits = because they are two hard to implement so the data needs to "go along" = with the command.=20 [Chris Boulton] Agreed. If you accept we have to have the above, I rather have a small command = set than a large one because I think a small set will do. [Chris Boulton] Again, Agreed. Command set certainly doesn't need to be = large.=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. _______________________________________________ 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 Thu Feb 02 14:49:03 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 1F4kRz-0003Ce-LU; Thu, 02 Feb 2006 14:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kRx-00031A-HL for xcon@megatron.ietf.org; Thu, 02 Feb 2006 14:49:01 -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 OAA03688 for ; Thu, 2 Feb 2006 14:47:19 -0500 (EST) Received: from dsl027-191-186.sfo1.dsl.speakeasy.net ([216.27.191.186] helo=email.tello.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4kdI-0000dK-7V for xcon@ietf.org; Thu, 02 Feb 2006 15:00:45 -0500 Received: from [192.168.30.40] (71-81-78-136.dhcp.stls.mo.charter.com [71.81.78.136]) by email.tello.com (Postfix) with ESMTP id D418AA00CE; Thu, 2 Feb 2006 11:46:44 -0800 (PST) Message-ID: <43E26203.2070107@tello.com> Date: Thu, 02 Feb 2006 11:48:19 -0800 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson Subject: Re: [XCON] =?ISO-8859-1?Q?Chair=B4s_opinion_=3A=29?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-tello-MailScanner-Information: Please contact the ISP for more information X-tello-MailScanner: Found to be clean X-tello-MailScanner-From: ajohnston@tello.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , adam@nostrum.com, Chris Boulton , 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 (not as chair) Sean Olson wrote: >Yeah, not sure I understand the terminology either ... What is the purpo= se of the command if it does not involve some amount of data manipulation= ? The command set doesn't need to be large, but hopefully it is not just = 4 commands (get, set, create, delete) ;-) > > =20 > This is exactly my point. A data manipulation only approach would only=20 have get, set, create, and delete. Examples of conference control=20 commands that are not covered by these include "create a conference",=20 "delete a conference", "bring the sidebar participants back into the=20 main conference", etc. Do we need these? My terminology use was not intended to bias the discussion - we had=20 never been able to agree on the right term in the past so I tried=20 another one.=20 Anyway, this discussion is exactly the one I wanted to have. If we standardize two "transports" then they have to be equivalent -=20 there needs to be clear mapping between them with the same set of=20 features and services covered, in my personal opinion. This way, it is=20 like SIP using both UDP and TCP. Thanks, Alan >-----Original Message----- >From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Chris Boulton >Sent: Thursday, February 02, 2006 4:03 AM >To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF) >Cc: adam@nostrum.com; XCON-IETF >Subject: RE: [XCON] Chair=B4s opinion :) > > > > =20 > >>However, I still think we need to decide the fundamental question of=20 >>whether conference control is about data manipulation alone, data=20 >>manipulation plus commands, or purely command based. I would like to=20 >>see this addressed. The working group consensus on this will validate=20 >>whether multiple transports or bindings will even work. >> =20 >> > >I think this terminology heavily bias the decision but continuing on wit= h it ... > >Given how we have data in the server that is defined after the client is= compiled, I think there *has* to be some of what you call data manipulat= ion (though there could be toher things too). If someone disagrees with t= his, then I am probably misunderstanding the terms. > >[Chris Boulton] Agreed. > >I also think that with any command, you may have situations where you ha= ve to set data at the same point. And I don't want two phase commits beca= use they are two hard to implement so the data needs to "go along" with t= he command.=20 > >[Chris Boulton] Agreed. > >If you accept we have to have the above, I rather have a small command s= et than a large one because I think a small set will do. > >[Chris Boulton] Again, Agreed. Command set certainly doesn't need to be= large.=20 > > >Information contained in this e-mail and any attachments are intended fo= r the use of the addressee only, and may contain confidential information= of Ubiquity Software Corporation. All unauthorized use, disclosure or d= istribution is strictly prohibited. If you are not the addressee, please= notify the sender immediately and destroy all copies of this email. Unl= ess otherwise expressly agreed in writing signed by an officer of Ubiquit= y 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 > > > =20 > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Feb 02 14:56:48 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 1F4kZU-0006n6-7L; Thu, 02 Feb 2006 14:56:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kZS-0006kJ-57 for xcon@megatron.ietf.org; Thu, 02 Feb 2006 14:56:46 -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 OAA04232 for ; Thu, 2 Feb 2006 14:55:09 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4kkq-0000tm-53 for xcon@ietf.org; Thu, 02 Feb 2006 15:08:35 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 2 Feb 2006 11:56:32 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 11:56:31 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 11:56:31 -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); Thu, 2 Feb 2006 11:56:30 -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: =?iso-8859-1?Q?RE=3A_=5BXCON=5D_Chair=B4s_opinion_=3A=29?= Date: Thu, 2 Feb 2006 11:56:29 -0800 Message-ID: In-Reply-To: <43E26203.2070107@tello.com> Thread-Topic: =?iso-8859-1?Q?=5BXCON=5D_Chair=B4s_opinion_=3A=29?= thread-index: AcYoMbB8GRIssGIySQi6Cbh4MfVSjgAAMw/A From: "Sean Olson" To: "Alan Johnston" X-OriginalArrivalTime: 02 Feb 2006 19:56:30.0876 (UTC) FILETIME=[C2D395C0:01C62832] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , adam@nostrum.com, Chris Boulton , 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 My (biased) opinion is that data manipulation (get, set, create, delete) = is not enough because it does not accurately capture the complex = semantics of some operations like "bring sidebar participants back into = the main conference". Data manipulation implies the intended operation; = commands explicitly define the intended operation. This makes it much = easier to implement more complex operations.=20 -----Original Message----- From: Alan Johnston [mailto:ajohnston@tello.com]=20 Sent: Thursday, February 02, 2006 11:48 AM To: Sean Olson Cc: Chris Boulton; Cullen Jennings; Oscar Novo (JO/LMF); = adam@nostrum.com; XCON-IETF Subject: Re: [XCON] Chair=B4s opinion :) (not as chair) Sean Olson wrote: >Yeah, not sure I understand the terminology either ... What is the=20 >purpose of the command if it does not involve some amount of data=20 >manipulation? The command set doesn't need to be large, but hopefully=20 >it is not just 4 commands (get, set, create, delete) ;-) > > =20 > This is exactly my point. A data manipulation only approach would only = have get, set, create, and delete. Examples of conference control = commands that are not covered by these include "create a conference", = "delete a conference", "bring the sidebar participants back into the = main conference", etc. Do we need these? My terminology use was not intended to bias the discussion - we had = never been able to agree on the right term in the past so I tried = another one.=20 Anyway, this discussion is exactly the one I wanted to have. If we standardize two "transports" then they have to be equivalent - = there needs to be clear mapping between them with the same set of = features and services covered, in my personal opinion. This way, it is = like SIP using both UDP and TCP. Thanks, Alan >-----Original Message----- >From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = >Chris Boulton >Sent: Thursday, February 02, 2006 4:03 AM >To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF) >Cc: adam@nostrum.com; XCON-IETF >Subject: RE: [XCON] Chair=B4s opinion :) > > > > =20 > >>However, I still think we need to decide the fundamental question of=20 >>whether conference control is about data manipulation alone, data=20 >>manipulation plus commands, or purely command based. I would like to=20 >>see this addressed. The working group consensus on this will validate = >>whether multiple transports or bindings will even work. >> =20 >> > >I think this terminology heavily bias the decision but continuing on = with it ... > >Given how we have data in the server that is defined after the client = is compiled, I think there *has* to be some of what you call data = manipulation (though there could be toher things too). If someone = disagrees with this, then I am probably misunderstanding the terms. > >[Chris Boulton] Agreed. > >I also think that with any command, you may have situations where you = have to set data at the same point. And I don't want two phase commits = because they are two hard to implement so the data needs to "go along" = with the command.=20 > >[Chris Boulton] Agreed. > >If you accept we have to have the above, I rather have a small command = set than a large one because I think a small set will do. > >[Chris Boulton] Again, Agreed. Command set certainly doesn't need to = be large.=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. > > >_______________________________________________ >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 From xcon-bounces@ietf.org Thu Feb 02 15:20: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 1F4kw2-00007D-SF; Thu, 02 Feb 2006 15:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kw1-000059-6V for xcon@megatron.ietf.org; Thu, 02 Feb 2006 15:20:05 -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 PAA05725 for ; Thu, 2 Feb 2006 15:18:17 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4l7I-0001ZP-DJ for xcon@ietf.org; Thu, 02 Feb 2006 15:31:44 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F4kvM-0006mE-9T; Thu, 02 Feb 2006 14:19:24 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Alan Johnston'" Subject: =?iso-8859-1?Q?RE:_=5BXCON=5D_Chair=B4s_opinion_:=29?= Date: Thu, 2 Feb 2006 15:16:39 -0500 Message-ID: <039501c62835$95938a90$2b6414ac@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: AcYoMbB8GRIssGIySQi6Cbh4MfVSjgAAMw/AAABFSnA= 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: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: 'Cullen Jennings' , 'Chris Boulton' , adam@nostrum.com, 'XCON-IETF' 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 Generally, I agree that we need more than set/get. OTOH, I don't want a zillion operators, and an invitation for each = template to invent more. I think we want to do two things: a) think hard about the data structures so set/get does what we want b) put a very high threshold on what constitutes an operation we have a special "method" for I'm not sure what it means to "bring sidebar participants back in the = main conference", but if it means (for an audio conference) change the mixer = so that what sidebar participants say is heard by main conference = participants, and that state is transient (that is, you want a "button" with two = states that moves them back and forth) then I want a datum ("sidebar enable") = in the sidebar data structure that can be set to true/false, and not a = method. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Thursday, February 02, 2006 2:56 PM To: Alan Johnston Cc: Cullen Jennings; adam@nostrum.com; Chris Boulton; XCON-IETF Subject: RE: [XCON] Chair=B4s opinion :) My (biased) opinion is that data manipulation (get, set, create, delete) = is not enough because it does not accurately capture the complex semantics = of some operations like "bring sidebar participants back into the main conference". Data manipulation implies the intended operation; commands explicitly define the intended operation. This makes it much easier to implement more complex operations.=20 -----Original Message----- From: Alan Johnston [mailto:ajohnston@tello.com]=20 Sent: Thursday, February 02, 2006 11:48 AM To: Sean Olson Cc: Chris Boulton; Cullen Jennings; Oscar Novo (JO/LMF); = adam@nostrum.com; XCON-IETF Subject: Re: [XCON] Chair=B4s opinion :) (not as chair) Sean Olson wrote: >Yeah, not sure I understand the terminology either ... What is the=20 >purpose of the command if it does not involve some amount of data=20 >manipulation? The command set doesn't need to be large, but hopefully=20 >it is not just 4 commands (get, set, create, delete) ;-) > > =20 > This is exactly my point. A data manipulation only approach would only = have get, set, create, and delete. Examples of conference control commands = that are not covered by these include "create a conference", "delete a conference", "bring the sidebar participants back into the main = conference", etc. Do we need these? My terminology use was not intended to bias the discussion - we had = never been able to agree on the right term in the past so I tried another one. = Anyway, this discussion is exactly the one I wanted to have. If we standardize two "transports" then they have to be equivalent - = there needs to be clear mapping between them with the same set of features and services covered, in my personal opinion. This way, it is like SIP = using both UDP and TCP. Thanks, Alan >-----Original Message----- >From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = >Chris Boulton >Sent: Thursday, February 02, 2006 4:03 AM >To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF) >Cc: adam@nostrum.com; XCON-IETF >Subject: RE: [XCON] Chair=B4s opinion :) > > > > =20 > >>However, I still think we need to decide the fundamental question of=20 >>whether conference control is about data manipulation alone, data=20 >>manipulation plus commands, or purely command based. I would like to=20 >>see this addressed. The working group consensus on this will validate = >>whether multiple transports or bindings will even work. >> =20 >> > >I think this terminology heavily bias the decision but continuing on = with it ... > >Given how we have data in the server that is defined after the client = is compiled, I think there *has* to be some of what you call data = manipulation (though there could be toher things too). If someone disagrees with = this, then I am probably misunderstanding the terms. > >[Chris Boulton] Agreed. > >I also think that with any command, you may have situations where you = have to set data at the same point. And I don't want two phase commits = because they are two hard to implement so the data needs to "go along" with the command.=20 > >[Chris Boulton] Agreed. > >If you accept we have to have the above, I rather have a small command = set than a large one because I think a small set will do. > >[Chris Boulton] Again, Agreed. Command set certainly doesn't need to = be large.=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. > > >_______________________________________________ >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 Thu Feb 02 15:53:17 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 1F4lS9-0007jK-98; Thu, 02 Feb 2006 15:53:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4lS6-0007hG-W8 for xcon@megatron.ietf.org; Thu, 02 Feb 2006 15:53:16 -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 PAA08284 for ; Thu, 2 Feb 2006 15:51:34 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ldV-0002qS-GC for xcon@ietf.org; Thu, 02 Feb 2006 16:05:02 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 2 Feb 2006 12:53:02 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 12:53:01 -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: =?iso-8859-1?Q?RE=3A_=5BXCON=5D_Chair=B4s_opinion_=3A=29?= Date: Thu, 2 Feb 2006 12:52:11 -0800 Message-ID: Thread-Topic: =?iso-8859-1?Q?=5BXCON=5D_Chair=B4s_opinion_=3A=29?= Thread-Index: AcYoMbB8GRIssGIySQi6Cbh4MfVSjgAAMw/AAABFSnAAAZHJsA== From: "Orit Levin" To: , "Sean Olson" , "Alan Johnston" X-OriginalArrivalTime: 02 Feb 2006 20:53:01.0449 (UTC) FILETIME=[A7C3F790:01C6283A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Chris Boulton , adam@nostrum.com, 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 Brian, I also suggest that you use WAP as the requirement for defining the = template data model and be done with it :-) Orit. > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf = Of > Brian Rosen > Sent: Thursday, February 02, 2006 12:17 PM > To: Sean Olson; 'Alan Johnston' > Cc: 'Cullen Jennings'; 'Chris Boulton'; adam@nostrum.com; 'XCON-IETF' > Subject: RE: [XCON] Chair=B4s opinion :) >=20 > Generally, I agree that we need more than set/get. > OTOH, I don't want a zillion operators, and an invitation for each > template > to invent more. > I think we want to do two things: > a) think hard about the data structures so set/get does what we want > b) put a very high threshold on what constitutes an operation we > have > a special "method" for >=20 > I'm not sure what it means to "bring sidebar participants back in the = main > conference", but if it means (for an audio conference) change the = mixer so > that what sidebar participants say is heard by main conference > participants, > and that state is transient (that is, you want a "button" with two = states > that moves them back and forth) then I want a datum ("sidebar enable") = in > the sidebar data structure that can be set to true/false, and not a > method. >=20 > Brian >=20 > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf = Of > Sean > Olson > Sent: Thursday, February 02, 2006 2:56 PM > To: Alan Johnston > Cc: Cullen Jennings; adam@nostrum.com; Chris Boulton; XCON-IETF > Subject: RE: [XCON] Chair=B4s opinion :) >=20 > My (biased) opinion is that data manipulation (get, set, create, = delete) > is > not enough because it does not accurately capture the complex = semantics of > some operations like "bring sidebar participants back into the main > conference". Data manipulation implies the intended operation; = commands > explicitly define the intended operation. This makes it much easier to > implement more complex operations. >=20 > -----Original Message----- > From: Alan Johnston [mailto:ajohnston@tello.com] > Sent: Thursday, February 02, 2006 11:48 AM > To: Sean Olson > Cc: Chris Boulton; Cullen Jennings; Oscar Novo (JO/LMF); = adam@nostrum.com; > XCON-IETF > Subject: Re: [XCON] Chair=B4s opinion :) >=20 > (not as chair) >=20 > Sean Olson wrote: >=20 > >Yeah, not sure I understand the terminology either ... What is the > >purpose of the command if it does not involve some amount of data > >manipulation? The command set doesn't need to be large, but hopefully > >it is not just 4 commands (get, set, create, delete) ;-) > > > > > > > This is exactly my point. A data manipulation only approach would = only > have > get, set, create, and delete. Examples of conference control commands > that > are not covered by these include "create a conference", "delete a > conference", "bring the sidebar participants back into the main > conference", > etc. Do we need these? >=20 > My terminology use was not intended to bias the discussion - we had = never > been able to agree on the right term in the past so I tried another = one. > Anyway, this discussion is exactly the one I wanted to have. >=20 > If we standardize two "transports" then they have to be equivalent - = there > needs to be clear mapping between them with the same set of features = and > services covered, in my personal opinion. This way, it is like SIP = using > both UDP and TCP. >=20 > Thanks, > Alan >=20 > >-----Original Message----- > >From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf = Of > >Chris Boulton > >Sent: Thursday, February 02, 2006 4:03 AM > >To: Cullen Jennings; Alan Johnston; Oscar Novo (JO/LMF) > >Cc: adam@nostrum.com; XCON-IETF > >Subject: RE: [XCON] Chair=B4s opinion :) > > > > > > > > > > > >>However, I still think we need to decide the fundamental question of > >>whether conference control is about data manipulation alone, data > >>manipulation plus commands, or purely command based. I would like = to > >>see this addressed. The working group consensus on this will = validate > >>whether multiple transports or bindings will even work. > >> > >> > > > >I think this terminology heavily bias the decision but continuing on = with > it ... > > > >Given how we have data in the server that is defined after the client = is > compiled, I think there *has* to be some of what you call data > manipulation > (though there could be toher things too). If someone disagrees with = this, > then I am probably misunderstanding the terms. > > > >[Chris Boulton] Agreed. > > > >I also think that with any command, you may have situations where you > have > to set data at the same point. And I don't want two phase commits = because > they are two hard to implement so the data needs to "go along" with = the > command. > > > >[Chris Boulton] Agreed. > > > >If you accept we have to have the above, I rather have a small = command > set > than a large one because I think a small set will do. > > > >[Chris Boulton] Again, Agreed. Command set certainly doesn't need to = be > large. > > > > > >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 > > > > > > > > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=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 Thu Feb 02 20:41: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 1F4px2-0005Gz-PI; Thu, 02 Feb 2006 20:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pwu-0005EI-Pk for xcon@megatron.ietf.org; Thu, 02 Feb 2006 20:41:27 -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 UAA09236 for ; Thu, 2 Feb 2006 20:39:32 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4q8D-00083Y-5y for xcon@ietf.org; Thu, 02 Feb 2006 20:53:02 -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 k131bd6j014032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Feb 2006 20:41:06 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k131bMLO013293; Thu, 2 Feb 2006 20:37:22 -0500 Message-ID: <43E2785E.6040703@cs.columbia.edu> Date: Thu, 02 Feb 2006 16:23:42 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [XCON] Conference Control References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: > >> I do not however agree that a decision to >> use a binary encoding for floor control necessarily means we should >> generally be constrained to use a binary encoding for conference >> control. > > I certainly have mixed feelings on this myself. I do think that it makes a > fairly strong argument that we need to at least have one protocol that > supports the functionality and is usable in the same environment that BFCP > was designed for. That does not stop us from having a second protocol with > the same functionality that does not work in the environment BFCP was > designed for. > > I'm pretty sure that I did point this all out back when we approved BFCP > that selecting one of the key protocols before having even a rough idea on > the architecture was going to constrain our options later and that if we > were accepting the BFCP requirements, well we had to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem with > this back when we did BFCP. Ironically, I was the one of the only people > that had any reservations about BFCP. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 03 03:29: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 1F4wK8-000069-W8; Fri, 03 Feb 2006 03:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wK1-00004q-Kp for xcon@megatron.ietf.org; Fri, 03 Feb 2006 03:29: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 DAA04921 for ; Fri, 3 Feb 2006 03:27:50 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4wVK-0003oZ-7S for xcon@ietf.org; Fri, 03 Feb 2006 03:41:23 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 30105CB3; Fri, 3 Feb 2006 09:29:04 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 09:29:03 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 09:29:03 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Conference Control Date: Fri, 3 Feb 2006 09:29:01 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYoZbQgS0Z9hQCATyGpK6ekRmWLFwAM95Mg From: "Oscar Novo \(JO/LMF\)" To: "Henning Schulzrinne" , "Cullen Jennings" X-OriginalArrivalTime: 03 Feb 2006 08:29:03.0724 (UTC) FILETIME=[E4056AC0:01C6289B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Hello Henning, Comments inline.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Henning Schulzrinne Sent: 2. helmikuuta 2006 23:24 To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion = of real-time needs, this appears far less of an issue for creating and = managing conferences.=20 [ON]There are some cases managing a conference where the real-time needs = in CCP is important, for instance, "mute" a user in a conference, or = "eject" a user from a conference. In addition, many of the items that needed for conference creation are = naturally strings, such as descriptions or URIs.=20 I'd be surprised if a binary approach were to offer significant = improvements in effective length, particularly once compression has been = applied. [ON] The fact that in the binary approach you don=B4t need compression = is a significants improvement respect the other proposals. Compression = requires more CPU processing and adds "latency". Compression is a = solution for limited bandwidth but not for latency. You can compress the = data, but latency is still there.=20 Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to = >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had = > to accept them for enough to do xcon conferences on that sort of=20 > device, and that would imply similar constraints on the other=20 > protocols. No one seemed to have a problem with this back when we did = > BFCP. Ironically, I was the one of the only people that had any = reservations about BFCP. _______________________________________________ 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 Feb 03 08:17: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 1F50dx-0001Ta-Ea; Fri, 03 Feb 2006 08:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F50da-0001Oi-3e for xcon@megatron.ietf.org; Fri, 03 Feb 2006 08:06: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 IAA22714 for ; Fri, 3 Feb 2006 08:04:20 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F50by-000689-MB for xcon@ietf.org; Fri, 03 Feb 2006 08:04:27 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F50PY-0001C4-Lg; Fri, 03 Feb 2006 06:51:37 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Cullen Jennings'" Subject: RE: [XCON] Conference Control Date: Fri, 3 Feb 2006 07:48:59 -0500 Message-ID: <04f201c628c0$365638d0$2b6414ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3Mw In-Reply-To: <43E2785E.6040703@cs.columbia.edu> 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: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: 'Chris Boulton' , 'Adam Roach' , ajohnston@tello.com, 'XCON-IETF' 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 If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: > >> I do not however agree that a decision to >> use a binary encoding for floor control necessarily means we should >> generally be constrained to use a binary encoding for conference >> control. > > I certainly have mixed feelings on this myself. I do think that it makes a > fairly strong argument that we need to at least have one protocol that > supports the functionality and is usable in the same environment that BFCP > was designed for. That does not stop us from having a second protocol with > the same functionality that does not work in the environment BFCP was > designed for. > > I'm pretty sure that I did point this all out back when we approved BFCP > that selecting one of the key protocols before having even a rough idea on > the architecture was going to constrain our options later and that if we > were accepting the BFCP requirements, well we had to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem with > this back when we did BFCP. Ironically, I was the one of the only people > that had any reservations about BFCP. _______________________________________________ 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 Feb 03 09:28:35 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 1F51vP-0007af-St; Fri, 03 Feb 2006 09:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51vO-0007Y6-Cx for xcon@megatron.ietf.org; Fri, 03 Feb 2006 09:28:34 -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 JAA02778 for ; Fri, 3 Feb 2006 09:26:56 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F526y-0003yM-Ia for xcon@ietf.org; Fri, 03 Feb 2006 09:40:33 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k13ESM32015267 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 3 Feb 2006 09:28:23 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DAC531C-D16A-4B07-808A-3CC49259F91E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [XCON] Conference Control Date: Fri, 3 Feb 2006 09:28:07 -0500 To: Oscar Novo ((JO/LMF)) X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Have you actually measured the latency for compression? We're probably talking 2-3 ms here, based on my experience. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 03 10:08: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 1F52YL-0004Bu-4U; Fri, 03 Feb 2006 10:08:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52YJ-00045B-35 for xcon@megatron.ietf.org; Fri, 03 Feb 2006 10:08:47 -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 KAA07587 for ; Fri, 3 Feb 2006 10:07:04 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F52jp-0005t0-Gq for xcon@ietf.org; Fri, 03 Feb 2006 10:20:41 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F52Xg-0006XR-Fa; Fri, 03 Feb 2006 09:08:08 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Oscar Novo \(\(JO/LMF\)\)'" Subject: RE: [XCON] Conference Control Date: Fri, 3 Feb 2006 10:06:00 -0500 Message-ID: <000f01c628d3$5a39b660$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYozuZfC3SU4i54TIGhcQvTg+AI4AAA9vhQ In-Reply-To: <7DAC531C-D16A-4B07-808A-3CC49259F91E@cs.columbia.edu> 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , 'Chris Boulton' , 'Adam Roach' , ajohnston@tello.com, 'XCON-IETF' 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 I don't see a problem. This is not in a media channel, it's in a control channel. You could have 100 ms latency and not really notice. In this case, the latency would be the time from when your UI recorded a button press, and the time the received audio (say) changed in response. That would be a one way (assuming no error) message on the control channel, processing at both ends for the message, the actual change to mixer state, and the delay in getting the next packet out of the mixer to the receiver audio subsystem. The packetization delay on the audio is 15-20 ms of that. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, February 03, 2006 9:28 AM To: Oscar Novo ((JO/LMF)) Cc: Cullen Jennings; Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control Have you actually measured the latency for compression? We're probably talking 2-3 ms here, based on my experience. _______________________________________________ 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 Feb 03 13:32:29 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 1F55jR-0006fC-MA; Fri, 03 Feb 2006 13:32:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F55jG-0006cq-0a for xcon@megatron.ietf.org; Fri, 03 Feb 2006 13:32:27 -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 NAA27120 for ; Fri, 3 Feb 2006 13:30:30 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F55uk-0006SM-3d for xcon@ietf.org; Fri, 03 Feb 2006 13:44:11 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Feb 2006 10:31:56 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:31:56 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:31:55 -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, 3 Feb 2006 10:31:55 -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, 3 Feb 2006 10:31:54 -0800 Message-ID: In-Reply-To: Thread-Topic: [XCON] Conference Control thread-index: AcYoZbQgS0Z9hQCATyGpK6ekRmWLFwAM95MgABWSaQA= From: "Sean Olson" To: "Oscar Novo \(JO/LMF\)" , "Henning Schulzrinne" , "Cullen Jennings" X-OriginalArrivalTime: 03 Feb 2006 18:31:55.0514 (UTC) FILETIME=[1C168DA0:01C628F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 =20 [HS] In addition, many of the items that needed for conference creation = are naturally strings, such as descriptions or URIs.=20 I'd be surprised if a binary approach were to offer significant = improvements in effective length, particularly once compression has been = applied. [ON] The fact that in the binary approach you don=B4t need compression = is a significants improvement respect the other proposals. Compression = requires more CPU processing and adds "latency". Compression is a = solution for limited bandwidth but not for latency. You can compress the = data, but latency is still there.=20 [SO]A string is a string. What is the "binary" encoding for a SIP URI = besides UTF-8?=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 03 13:35:31 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 1F55mN-0000HW-N3; Fri, 03 Feb 2006 13:35:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F55mK-0000GV-2K for xcon@megatron.ietf.org; Fri, 03 Feb 2006 13:35:31 -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 NAA27343 for ; Fri, 3 Feb 2006 13:33:40 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F55xp-0006ZC-3s for xcon@ietf.org; Fri, 03 Feb 2006 13:47:21 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Feb 2006 10:35:09 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:35:08 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:35:07 -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, 3 Feb 2006 10:35:07 -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: [XCON] Conference Control Date: Fri, 3 Feb 2006 10:35:06 -0800 Message-ID: In-Reply-To: <04f201c628c0$365638d0$2b6414ac@cis.neustar.com> Thread-Topic: [XCON] Conference Control thread-index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVA= From: "Sean Olson" To: , "Henning Schulzrinne" , "Cullen Jennings" X-OriginalArrivalTime: 03 Feb 2006 18:35:07.0659 (UTC) FILETIME=[8E9D8DB0:01C628F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Feb 03 13:36: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 1F55nG-0001Nc-Qv; Fri, 03 Feb 2006 13:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F55nG-0001M4-1h for xcon@megatron.ietf.org; Fri, 03 Feb 2006 13:36:26 -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 NAA27425 for ; Fri, 3 Feb 2006 13:34:38 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F55yl-0006bK-7c for xcon@ietf.org; Fri, 03 Feb 2006 13:48:19 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Feb 2006 10:36:08 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:36:08 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:36:07 -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, 3 Feb 2006 10:36:07 -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: [XCON] Conference Control Date: Fri, 3 Feb 2006 10:36:06 -0800 Message-ID: In-Reply-To: <000f01c628d3$5a39b660$640fa8c0@cis.neustar.com> Thread-Topic: [XCON] Conference Control thread-index: AcYozuZfC3SU4i54TIGhcQvTg+AI4AAA9vhQAAd3WtA= From: "Sean Olson" To: , "Henning Schulzrinne" , "Oscar Novo \(\(JO/LMF\)\)" X-OriginalArrivalTime: 03 Feb 2006 18:36:07.0514 (UTC) FILETIME=[B24AB3A0:01C628F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Completely agree. We should not be worrying about latency for the control channel at this level of granularity.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 7:06 AM To: 'Henning Schulzrinne'; 'Oscar Novo ((JO/LMF))' Cc: 'Cullen Jennings'; 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control I don't see a problem. This is not in a media channel, it's in a control channel. You could have 100 ms latency and not really notice. In this case, the latency would be the time from when your UI recorded a button press, and the time the received audio (say) changed in response. That would be a one way (assuming no error) message on the control channel, processing at both ends for the message, the actual change to mixer state, and the delay in getting the next packet out of the mixer to the receiver audio subsystem. The packetization delay on the audio is 15-20 ms of that. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, February 03, 2006 9:28 AM To: Oscar Novo ((JO/LMF)) Cc: Cullen Jennings; Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control Have you actually measured the latency for compression? We're probably talking 2-3 ms here, based on my experience. _______________________________________________ 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 Feb 03 13:58:34 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 1F568g-00037z-RJ; Fri, 03 Feb 2006 13:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F568e-00033Q-Dh for xcon@megatron.ietf.org; Fri, 03 Feb 2006 13:58:32 -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 NAA29175 for ; Fri, 3 Feb 2006 13:56:55 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F56KG-0007fJ-RP for xcon@ietf.org; Fri, 03 Feb 2006 14:10:34 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F567W-0005zU-Q1; Fri, 03 Feb 2006 12:57:23 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Henning Schulzrinne'" , "'Cullen Jennings'" Subject: RE: [XCON] Conference Control Date: Fri, 3 Feb 2006 13:55:09 -0500 Message-ID: <005701c628f3$5cd11c90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsA== In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen 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: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: 'Chris Boulton' , 'Adam Roach' , ajohnston@tello.com, 'XCON-IETF' 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 All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, but there are sidebars. Sidebar is "media" control - who sees what you type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message to change what we do with a fixed channel. Might want to think about making IM work that way for consistency. I think Aki would have some misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, over this protocol, are likely to be media control messages, for which set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less. -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: > >> I do not however agree that a decision to use a binary encoding for >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. > > I certainly have mixed feelings on this myself. I do think that it > makes a fairly strong argument that we need to at least have one > protocol that supports the functionality and is usable in the same > environment that BFCP was designed for. That does not stop us from > having a second protocol with the same functionality that does not > work in the environment BFCP was designed for. > > I'm pretty sure that I did point this all out back when we approved > BFCP that selecting one of the key protocols before having even a > rough idea on the architecture was going to constrain our options > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Feb 03 14:20: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 1F56Tk-00026d-CQ; Fri, 03 Feb 2006 14:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F56Ti-00025c-3C for xcon@megatron.ietf.org; Fri, 03 Feb 2006 14:20: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 OAA00952 for ; Fri, 3 Feb 2006 14:18:32 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F56fC-0008Sa-Dy for xcon@ietf.org; Fri, 03 Feb 2006 14:32:12 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Feb 2006 11:19:58 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 11:19:58 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 11:19:57 -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, 3 Feb 2006 11:19:57 -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: [XCON] Conference Control Date: Fri, 3 Feb 2006 11:19:55 -0800 Message-ID: In-Reply-To: <005701c628f3$5cd11c90$640fa8c0@cis.neustar.com> Thread-Topic: [XCON] Conference Control thread-index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQ From: "Sean Olson" To: , "Henning Schulzrinne" , "Cullen Jennings" X-OriginalArrivalTime: 03 Feb 2006 19:19:57.0534 (UTC) FILETIME=[D1E7E7E0:01C628F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User=20 - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, obviously, apply to conferences with other media types as well. You'll also notice that most of the parameters to these would be strings where binary encoding won't help. These are also not as time sensitive as other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, but there are sidebars. Sidebar is "media" control - who sees what you type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message to change what we do with a fixed channel. Might want to think about making IM work that way for consistency. I think Aki would have some misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, over this protocol, are likely to be media control messages, for which set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Feb 03 15:24: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 1F57Tn-0002ai-RI; Fri, 03 Feb 2006 15:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57TT-0002Py-QF for xcon@megatron.ietf.org; Fri, 03 Feb 2006 15:24: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 PAA07183 for ; Fri, 3 Feb 2006 15:22:30 -0500 (EST) Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57f6-00030T-UB for xcon@ietf.org; Fri, 03 Feb 2006 15:36:10 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3206.me.freeserve.com (SMTP Server) with ESMTP id 352AD1C00089; Fri, 3 Feb 2006 21:23:40 +0100 (CET) Received: from RW (user-980.wfd85b.dsl.pol.co.uk [84.71.155.212]) by mwinf3206.me.freeserve.com (SMTP Server) with SMTP id A8A851C00085; Fri, 3 Feb 2006 21:23:39 +0100 (CET) X-ME-UUID: 20060203202339691.A8A851C00085@mwinf3206.me.freeserve.com Message-ID: <008b01c628ff$b82853e0$b100a8c0@RW> From: "Pete Cordell" To: "Sean Olson" , "Oscar Novo (JO/LMF)" , "Henning Schulzrinne" , "Cullen Jennings" References: Subject: Re: [XCON] Conference Control Date: Fri, 3 Feb 2006 20:23:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Don't know what the best message to inject this into this thread, but I h= ave=20 a compact text based encoding method that competes well with the less=20 aggressive binary encoding methods on message size (should compete well w= ith=20 BFCP level, but not ASN.1 PER level) that sounds ideal for these scenario= s. It has a formal message definition language and formal 'on-the-wire' spec= .=20 It's also very extensible by various methods (standards based and=20 proprietary). It's written up in a draft at=20 http://www.ietf.org/internet-drafts/draft-cordell-lumas-03.txt. There is a brief description of it at:=20 http://www.tech-know-ware.com/lumas/lumas-example.html There's C and Perl parsers, along with a message definition syntax checke= r=20 at http://tech-know-ware.com/lumas/. There is also the beginnings of a t= ool=20 that converts the message definition into an ABNF definition, so that you= =20 can use your favourite ABNF to code route, making it a risk free. HTH, Pete. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----- Original Message -----=20 From: "Sean Olson" To: "Oscar Novo (JO/LMF)" ; "Henning Schulzrinne= "=20 ; "Cullen Jennings" Cc: "Chris Boulton" ; "Adam Roach"=20 ; ; "XCON-IETF" Sent: Friday, February 03, 2006 6:31 PM Subject: RE: [XCON] Conference Control [HS] In addition, many of the items that needed for conference creation a= re=20 naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improveme= nts=20 in effective length, particularly once compression has been applied. [ON] The fact that in the binary approach you don=B4t need compression is= a=20 significants improvement respect the other proposals. Compression require= s=20 more CPU processing and adds "latency". Compression is a solution for=20 limited bandwidth but not for latency. You can compress the data, but=20 latency is still there. [SO]A string is a string. What is the "binary" encoding for a SIP URI=20 besides UTF-8? _______________________________________________ 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 Feb 03 15:39:08 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 1F57i0-00012E-Fw; Fri, 03 Feb 2006 15:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57hy-0000zl-OX for xcon@megatron.ietf.org; Fri, 03 Feb 2006 15:39:06 -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 PAA08403 for ; Fri, 3 Feb 2006 15:37:28 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57tc-0003dR-3h for xcon@ietf.org; Fri, 03 Feb 2006 15:51:09 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2006 12:38:56 -0800 X-IronPort-AV: i="4.02,85,1139212800"; d="scan'208"; a="400504553:sNHT31658496" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k13KcsWJ020668; Fri, 3 Feb 2006 12:38:56 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 15:38:55 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 15:38:54 -0500 Message-ID: <43E3BF5E.20403@cisco.com> Date: Fri, 03 Feb 2006 15:38:54 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [XCON] Conference Control References: <005701c628f3$5cd11c90$640fa8c0@cis.neustar.com> In-Reply-To: <005701c628f3$5cd11c90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2006 20:38:55.0005 (UTC) FILETIME=[D9A89CD0:01C62901] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , 'Chris Boulton' , 'Adam Roach' , ajohnston@tello.com, 'XCON-IETF' , 'Henning Schulzrinne' 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 Brian Rosen wrote: > All right, then let's talk about an IM conference. > Most of them, once established, don't do anything except send messages, but > there are sidebars. Sidebar is "media" control - who sees what you type. > You create a sidebar - that's in the noise part. You then send messages > inside the sidebar or in the main conference. It's an interesting > difference between audio/video conferences and IM conferences; with > audio/video, you don't send to a "channel", you send a control message to > change what we do with a fixed channel. Might want to think about making IM > work that way for consistency. I think Aki would have some misgivings... OR, you might want to think about changing voice/video conferences to work more like IM. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 03 15:45: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 1F57o8-00042E-0l; Fri, 03 Feb 2006 15:45:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57o5-00041v-9i for xcon@megatron.ietf.org; Fri, 03 Feb 2006 15:45: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 PAA08778 for ; Fri, 3 Feb 2006 15:43:47 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57zj-0003sk-6A for xcon@ietf.org; Fri, 03 Feb 2006 15:57:27 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F57nl-0001wd-HA; Fri, 03 Feb 2006 14:45:06 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Henning Schulzrinne'" , "'Cullen Jennings'" Subject: RE: [XCON] Conference Control Date: Fri, 3 Feb 2006 15:41:31 -0500 Message-ID: <008701c62902$3962af80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAAEqfnA= In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen 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: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: 'Chris Boulton' , 'Adam Roach' , ajohnston@tello.com, 'XCON-IETF' 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 Okay, that's what I thought. I can see a method which was add/delete/eject user from conference/sidebar One or three functions with parameters. I can see methods which is create/delete conference/sidebar Mute/Unmute would not be a method; that's a set/get of a datum Of course there is no difference here between IM and audio/video. The thing is, these are very low incidence messages. They are important, and unless we used a generic list management method, probably necessary. I certainly don't see these methods as influencing protocol choice. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, obviously, apply to conferences with other media types as well. You'll also notice that most of the parameters to these would be strings where binary encoding won't help. These are also not as time sensitive as other media control commands might be. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, but there are sidebars. Sidebar is "media" control - who sees what you type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message to change what we do with a fixed channel. Might want to think about making IM work that way for consistency. I think Aki would have some misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, over this protocol, are likely to be media control messages, for which set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less. -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: > >> I do not however agree that a decision to use a binary encoding for >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. > > I certainly have mixed feelings on this myself. I do think that it > makes a fairly strong argument that we need to at least have one > protocol that supports the functionality and is usable in the same > environment that BFCP was designed for. That does not stop us from > having a second protocol with the same functionality that does not > work in the environment BFCP was designed for. > > I'm pretty sure that I did point this all out back when we approved > BFCP that selecting one of the key protocols before having even a > rough idea on the architecture was going to constrain our options > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Feb 03 16:46:33 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 1F58lD-0004mK-HE; Fri, 03 Feb 2006 16:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58l9-0004hG-2B for xcon@megatron.ietf.org; Fri, 03 Feb 2006 16:46: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 QAA18212 for ; Fri, 3 Feb 2006 16:44:40 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F58we-00089C-Jj for xcon@ietf.org; Fri, 03 Feb 2006 16:58:22 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Feb 2006 13:46:08 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 13:46:07 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 13:46:07 -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, 3 Feb 2006 13:46:07 -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: [XCON] Conference Control Date: Fri, 3 Feb 2006 13:45:53 -0800 Message-ID: In-Reply-To: <008701c62902$3962af80$640fa8c0@cis.neustar.com> Thread-Topic: [XCON] Conference Control thread-index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAAEqfnAAA98jUA== From: "Sean Olson" To: , "Henning Schulzrinne" , "Cullen Jennings" X-OriginalArrivalTime: 03 Feb 2006 21:46:07.0190 (UTC) FILETIME=[3D073760:01C6290B] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Hmmm... I see your perspective, I just disagree. I have the reverse problem. I'd like to make sure we don't unduly influence the design of the conference control parts based on the media control parts.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, February 03, 2006 12:42 PM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control Okay, that's what I thought. I can see a method which was add/delete/eject user from conference/sidebar One or three functions with parameters. I can see methods which is create/delete conference/sidebar Mute/Unmute would not be a method; that's a set/get of a datum Of course there is no difference here between IM and audio/video. The thing is, these are very low incidence messages. They are important, and unless we used a generic list management method, probably necessary. I certainly don't see these methods as influencing protocol choice. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, obviously, apply to conferences with other media types as well. You'll also notice that most of the parameters to these would be strings where binary encoding won't help. These are also not as time sensitive as other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, but there are sidebars. Sidebar is "media" control - who sees what you type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message to change what we do with a fixed channel. Might want to think about making IM work that way for consistency. I think Aki would have some misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, over this protocol, are likely to be media control messages, for which set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Feb 03 17:33:38 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 1F59Uo-0005LA-GL; Fri, 03 Feb 2006 17:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59Um-0005Ig-Mc for xcon@megatron.ietf.org; Fri, 03 Feb 2006 17:33:36 -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 RAA22347 for ; Fri, 3 Feb 2006 17:31:57 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F59gR-0001no-PA for xcon@ietf.org; Fri, 03 Feb 2006 17:45:40 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F59UH-0005OK-6V; Fri, 03 Feb 2006 16:33:05 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [XCON] Conference Control Date: Fri, 3 Feb 2006 17:28:35 -0500 Message-ID: <010b01c62911$2dbafd90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYpAdtxoIc7/s1yTc26ggPmz8Zi/gAAIXcg In-Reply-To: <43E3BF5E.20403@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , 'Chris Boulton' , 'Adam Roach' , ajohnston@tello.com, 'XCON-IETF' , 'Henning Schulzrinne' 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 Well, I've thought of that, but it tends not to work. You have an audio channel (RTP stream) in, and another one out. If you tried to open another, the SBCs (and lots of silly proxies that shouldn't be looking) get confused. Try it, you won't like the results. It does work within an enterprise. Now, having said that, the same SBCs won't deal with video. Brian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, February 03, 2006 3:39 PM To: br@brianrosen.net Cc: 'Sean Olson'; 'Henning Schulzrinne'; 'Cullen Jennings'; 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: Re: [XCON] Conference Control Brian Rosen wrote: > All right, then let's talk about an IM conference. > Most of them, once established, don't do anything except send messages, but > there are sidebars. Sidebar is "media" control - who sees what you type. > You create a sidebar - that's in the noise part. You then send messages > inside the sidebar or in the main conference. It's an interesting > difference between audio/video conferences and IM conferences; with > audio/video, you don't send to a "channel", you send a control message to > change what we do with a fixed channel. Might want to think about making IM > work that way for consistency. I think Aki would have some misgivings... OR, you might want to think about changing voice/video conferences to work more like IM. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Feb 04 10:09: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 1F5P2a-00068D-Rq; Sat, 04 Feb 2006 10:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5P2V-00062X-3u for xcon@megatron.ietf.org; Sat, 04 Feb 2006 10:09:31 -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 KAA13143 for ; Sat, 4 Feb 2006 10:07:06 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5PDc-0006QH-Td for xcon@ietf.org; Sat, 04 Feb 2006 10:20:57 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k14F8OnR029074; Sat, 4 Feb 2006 09:08:24 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 4 Feb 2006 15:08:24 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB011E33E18@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Oscar Novo (JO/LMF)'" , "'Henning Schulzrinne'" Subject: RE: [XCON] Conference Control Date: Sat, 4 Feb 2006 15:08:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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'd be interested to know why this use cases cannot be met by using = floor control and conference control in parallel. If it is really = important to cut off a user from speaking as soon as possible and eject = that user from the conference, then floor control can solve the stop = from speaking issue. As for mute, then is that not really a function for the floor control = protocol anyway. Surely you are only putting it in the conference = control protocol due to potential absence of floor control protocol. regards Keith > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org]On Behalf = Of > Oscar Novo (JO/LMF) > Sent: 03 February 2006 08:29 > To: Henning Schulzrinne; Cullen Jennings > Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF > Subject: RE: [XCON] Conference Control >=20 >=20 > Hello Henning, >=20 > Comments inline.=20 >=20 > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20 > Behalf Of Henning Schulzrinne > Sent: 2. helmikuuta 2006 23:24 > To: Cullen Jennings > Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF > Subject: Re: [XCON] Conference Control >=20 > While floor control, in its push-to-talk usage at least, had=20 > some notion of real-time needs, this appears far less of an=20 > issue for creating and managing conferences.=20 >=20 > [ON]There are some cases managing a conference where the=20 > real-time needs in CCP is important, for instance, "mute" a=20 > user in a conference, or "eject" a user from a conference. >=20 > In addition, many of the items that needed for conference=20 > creation are naturally strings, such as descriptions or URIs.=20 > I'd be surprised if a binary approach were to offer=20 > significant improvements in effective length, particularly=20 > once compression has been applied. >=20 > [ON] The fact that in the binary approach you don=B4t need=20 > compression is a significants improvement respect the other=20 > proposals. Compression requires more CPU processing and adds=20 > "latency". Compression is a solution for limited bandwidth=20 > but not for latency. You can compress the data, but latency=20 > is still there.=20 >=20 > Thus, I don't see the analogy. >=20 > Cullen Jennings wrote: > > On 2/1/06 9:18 AM, "Sean Olson" wrote: > >=20 > >> I do not however agree that a decision to use a binary=20 > encoding for=20 > >> floor control necessarily means we should generally be=20 > constrained to=20 > >> use a binary encoding for conference control. > >=20 > > I certainly have mixed feelings on this myself. I do think that it=20 > > makes a fairly strong argument that we need to at least have one=20 > > protocol that supports the functionality and is usable in the same=20 > > environment that BFCP was designed for. That does not stop us from=20 > > having a second protocol with the same functionality that does not=20 > > work in the environment BFCP was designed for. > >=20 > > I'm pretty sure that I did point this all out back when we approved = > > BFCP that selecting one of the key protocols before having even a=20 > > rough idea on the architecture was going to constrain our options=20 > > later and that if we were accepting the BFCP requirements,=20 > well we had=20 > > to accept them for enough to do xcon conferences on that sort of=20 > > device, and that would imply similar constraints on the other=20 > > protocols. No one seemed to have a problem with this back=20 > when we did=20 > > BFCP. Ironically, I was the one of the only people that had=20 > any reservations about BFCP. >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Feb 04 21:53:58 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 1F5a2H-0007bA-Vx; Sat, 04 Feb 2006 21:53:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5a2B-0007Tk-SN for xcon@megatron.ietf.org; Sat, 04 Feb 2006 21:53:56 -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 VAA28685 for ; Sat, 4 Feb 2006 21:51:55 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5aDn-00064Y-Tl for xcon@ietf.org; Sat, 04 Feb 2006 22:05:52 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F5a1T-0003FK-Mj; Sat, 04 Feb 2006 20:53:07 -0600 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , "'Oscar Novo \(JO/LMF\)'" , "'Henning Schulzrinne'" Subject: RE: [XCON] Conference Control Date: Sat, 4 Feb 2006 21:50:56 -0500 Message-ID: <00a801c629fe$fe2d2000$3500000a@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: AcYpnRZ0ygysbjcWTIyG3CtOUx454AAYWvBA In-Reply-To: <475FF955A05DD411980D00508B6D5FB011E33E18@en0033exch001u.uk.lucent.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen 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: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: 'XCON-IETF' 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 I've never thought there was anything magic about floor control. It's = one of several relatively simple interactions between the conference = controller and a client that requires some notion of "real time" (100-300 ms if you need it). I've never thought that "ask for the floor" was any different from "mute" (of any flavor) or "change the contents of my main window to show George". They are all requests to change mixer state. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: Saturday, February 04, 2006 10:08 AM To: 'Oscar Novo (JO/LMF)'; 'Henning Schulzrinne' Cc: 'XCON-IETF' Subject: RE: [XCON] Conference Control I'd be interested to know why this use cases cannot be met by using = floor control and conference control in parallel. If it is really important to = cut off a user from speaking as soon as possible and eject that user from = the conference, then floor control can solve the stop from speaking issue. As for mute, then is that not really a function for the floor control protocol anyway. Surely you are only putting it in the conference = control protocol due to potential absence of floor control protocol. regards Keith > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org]On Behalf Of > Oscar Novo (JO/LMF) > Sent: 03 February 2006 08:29 > To: Henning Schulzrinne; Cullen Jennings > Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF > Subject: RE: [XCON] Conference Control >=20 >=20 > Hello Henning, >=20 > Comments inline.=20 >=20 > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20 > Behalf Of Henning Schulzrinne > Sent: 2. helmikuuta 2006 23:24 > To: Cullen Jennings > Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF > Subject: Re: [XCON] Conference Control >=20 > While floor control, in its push-to-talk usage at least, had=20 > some notion of real-time needs, this appears far less of an=20 > issue for creating and managing conferences.=20 >=20 > [ON]There are some cases managing a conference where the=20 > real-time needs in CCP is important, for instance, "mute" a=20 > user in a conference, or "eject" a user from a conference. >=20 > In addition, many of the items that needed for conference=20 > creation are naturally strings, such as descriptions or URIs.=20 > I'd be surprised if a binary approach were to offer=20 > significant improvements in effective length, particularly=20 > once compression has been applied. >=20 > [ON] The fact that in the binary approach you don=B4t need=20 > compression is a significants improvement respect the other=20 > proposals. Compression requires more CPU processing and adds=20 > "latency". Compression is a solution for limited bandwidth=20 > but not for latency. You can compress the data, but latency=20 > is still there.=20 >=20 > Thus, I don't see the analogy. >=20 > Cullen Jennings wrote: > > On 2/1/06 9:18 AM, "Sean Olson" wrote: > >=20 > >> I do not however agree that a decision to use a binary=20 > encoding for=20 > >> floor control necessarily means we should generally be=20 > constrained to=20 > >> use a binary encoding for conference control. > >=20 > > I certainly have mixed feelings on this myself. I do think that it=20 > > makes a fairly strong argument that we need to at least have one=20 > > protocol that supports the functionality and is usable in the same=20 > > environment that BFCP was designed for. That does not stop us from=20 > > having a second protocol with the same functionality that does not=20 > > work in the environment BFCP was designed for. > >=20 > > I'm pretty sure that I did point this all out back when we approved=20 > > BFCP that selecting one of the key protocols before having even a=20 > > rough idea on the architecture was going to constrain our options=20 > > later and that if we were accepting the BFCP requirements,=20 > well we had=20 > > to accept them for enough to do xcon conferences on that sort of=20 > > device, and that would imply similar constraints on the other=20 > > protocols. No one seemed to have a problem with this back=20 > when we did=20 > > BFCP. Ironically, I was the one of the only people that had=20 > any reservations about BFCP. >=20 >=20 > _______________________________________________ > 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 >=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 Tue Feb 07 21:57:51 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 1F6fWh-0007ke-UD; Tue, 07 Feb 2006 21:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6fWg-0007kM-5c for xcon@megatron.ietf.org; Tue, 07 Feb 2006 21:57: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 VAA06452 for ; Tue, 7 Feb 2006 21:56:02 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6fj6-0008FK-2h for xcon@ietf.org; Tue, 07 Feb 2006 22:10:40 -0500 X-IronPort-AV: i="4.02,96,1139202000"; d="scan'208"; a="27798955:sNHT46808280" 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: =?iso-8859-1?Q?Multiple_Protocol_Bindings_=28was_RE=3A_=5BXCON=5D_C?= =?iso-8859-1?Q?hair=B4s_opinion_=3A=29?= Date: Tue, 7 Feb 2006 21:58:23 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647022E0020@ATLANTIS.Brooktrout.com> Thread-Topic: =?iso-8859-1?Q?Multiple_Protocol_Bindings_=28was_RE=3A_=5BXCON=5D_C?= =?iso-8859-1?Q?hair=B4s_opinion_=3A=29?= Thread-Index: AcYnhqKLhmC+kV/GRTyoNoHQ4dxxTgEpcOqg From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable 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 will bite on the multiple protocol binding offer. If we can say with a straight face that the two, application-level = bindings of SOAP and CSCP are the same, we are saying that CSCP does = everything that SOAP does, including all of the support infrastructure = that SOAP brings. I seriously doubt that, and we are thus going to be = missing a bunch of functionality that you might not think is important, = but will be incredibly useful when it comes to creating the interesting = applications. Let us say that we really, really don't need the "baggage" of SOAP. = Then I would offer that if the handset manufacturers are adamant about = counting bits, and they get paid for having lots of stacks on the phone = (hey - it is a new feature!), then you will not see any SOAP bindings. = Why? If you have 300,000 handsets all talking CSCP, the application = server vendors MUST do CSCP (or die). Then, one has to ask why one = would build a SOAP binding? Oh yes - because the APPLICATIONS will come = from the web services side of the house. However, since it would be = hard to find interoperable implementations for PS, the "secondary" = transport gets dropped. Of course, we then find SOAP conference control bindings in OASYS or = (gasp) IMTC...=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Alan Johnston Sent: Wednesday, February 01, 2006 6:16 PM To: Oscar Novo (JO/LMF) Cc: Chris Boulton; adam@nostrum.com; xcon@ietf.org Subject: Re: [XCON] Chair=B4s opinion :) (as chair) I am encouraged by the level and direction of this discussion - lets=20 keep it up, everyone. Having multiple transports is possible, of course. Interop should be=20 possible by requiring servers to support both transports while clients=20 can support either. However, I still think we need to decide the fundamental question of=20 whether conference control is about data manipulation alone, data=20 manipulation plus commands, or purely command based. I would like to=20 see this addressed. The working group consensus on this will validate=20 whether multiple transports or bindings will even work. Thanks, Alan Johnston co-chair Oscar Novo (JO/LMF) wrote: >Yes, I think is good idea to know the chair's opinion in this = discussion It would be useful for everybody. :) > >Oscar > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 >Sent: 30. tammikuuta 2006 13:17 >To: br@brianrosen.net; Sean Olson; Henning Schulzrinne; Oscar Novo = (JO/LMF) >Cc: xcon@ietf.org >Subject: RE: [XCON] Conference Control > >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] >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: > =20 > >>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 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 > > > =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 Tue Feb 07 21:57: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 1F6fWp-0007m1-75; Tue, 07 Feb 2006 21:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6fWo-0007kb-9V for xcon@megatron.ietf.org; Tue, 07 Feb 2006 21:57:58 -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 VAA06450 for ; Tue, 7 Feb 2006 21:56:01 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6fj3-0008FK-HV for xcon@ietf.org; Tue, 07 Feb 2006 22:10:39 -0500 X-IronPort-AV: i="4.02,96,1139202000"; d="scan'208"; a="27798952:sNHT111021408" 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: [XCON] Conference Control Date: Tue, 7 Feb 2006 21:58:23 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647022E001F@ATLANTIS.Brooktrout.com> Thread-Topic: [XCON] Conference Control Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAM1WFtA= From: "Burger, Eric" To: "Sean Olson" X-Spam-Score: 1.1 (+) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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 Most of these commands have a URI. Last time I looked, URI's were 8-bits per character octets. Octets are binary. Octets are huge. Ask anyone who lived through the H.248 wars. Binary encodings ranged from 10% smaller than text to 3% larger. Transport compression effectively brought the PDU's to the same size. Why? Because the big win is not to say "DELETE CONFERENCE" in 3 bits but to be able to say "sip:muyser3241@extension.provider.example.net" in 8 bits. You can create a complex protocol that generates and hands around handles, or you can use a simple protocol, take the TLS library that is on the handset, and get the compression free.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Sean Olson Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User=20 - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, obviously, apply to conferences with other media types as well. You'll also notice that most of the parameters to these would be strings where binary encoding won't help. These are also not as time sensitive as other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, but there are sidebars. Sidebar is "media" control - who sees what you type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message to change what we do with a fixed channel. Might want to think about making IM work that way for consistency. I think Aki would have some misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, over this protocol, are likely to be media control messages, for which set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Tue Feb 07 22:05:04 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 1F6fdg-0002O8-1s; Tue, 07 Feb 2006 22:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6fcm-00029S-W5 for xcon@megatron.ietf.org; Tue, 07 Feb 2006 22:04:09 -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 WAA06797 for ; Tue, 7 Feb 2006 22:02:05 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6fox-0008Oy-5d for xcon@ietf.org; Tue, 07 Feb 2006 22:16:43 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Feb 2006 19:03:36 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 19:02:53 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 19:02:52 -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); Tue, 7 Feb 2006 19:02:52 -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: [XCON] Conference Control Date: Tue, 7 Feb 2006 19:02:50 -0800 Message-ID: In-Reply-To: <330A23D8336C0346B5C1A5BB19666647022E001F@ATLANTIS.Brooktrout.com> Thread-Topic: [XCON] Conference Control thread-index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAM1WFtAAC/nS4A== From: "Sean Olson" To: "Burger, Eric" X-OriginalArrivalTime: 08 Feb 2006 03:02:52.0050 (UTC) FILETIME=[2675B720:01C62C5C] X-Spam-Score: 1.1 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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'm a bit confused... I agree that TLS compression can help (btw, DEFLATE works quite well with XML and there are even better methods that are XML-specific) I agree that UTF-8 encoding of URIs means 8-bits per character in general (for ASCII at least) I don't see the leap of logic to take a SIP URI and cram it into 8 bits.... Other than generic token compression which I think we've already covered works as well for "text" as "binary"=20 -----Original Message----- From: Burger, Eric [mailto:eburger@brooktrout.com]=20 Sent: Tuesday, February 07, 2006 6:58 PM To: Sean Olson Cc: XCON-IETF Subject: RE: [XCON] Conference Control Most of these commands have a URI. Last time I looked, URI's were 8-bits per character octets. Octets are binary. Octets are huge. Ask anyone who lived through the H.248 wars. Binary encodings ranged from 10% smaller than text to 3% larger. Transport compression effectively brought the PDU's to the same size. Why? Because the big win is not to say "DELETE CONFERENCE" in 3 bits but to be able to say "sip:muyser3241@extension.provider.example.net" in 8 bits. You can create a complex protocol that generates and hands around handles, or you can use a simple protocol, take the TLS library that is on the handset, and get the compression free.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Sean Olson Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, obviously, apply to conferences with other media types as well. You'll also notice that most of the parameters to these would be strings where binary encoding won't help. These are also not as time sensitive as other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, but there are sidebars. Sidebar is "media" control - who sees what you type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message to change what we do with a fixed channel. Might want to think about making IM work that way for consistency. I think Aki would have some misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, over this protocol, are likely to be media control messages, for which set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- while those are very important types of media, I hope that we are not designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down in the couple percent range, will be the creation and upper management stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers are the norm. It also occurs to me, as I think of it, that we either want to use a learned dictionary compression system for the restricted bandwidth control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to adjust my volume control for your speech, "your" is indentified in the protocol as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 Wed Feb 08 08:56:19 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 1F6pnv-0004TU-2A; Wed, 08 Feb 2006 08:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pnd-0004Cy-HW for xcon@megatron.ietf.org; Wed, 08 Feb 2006 08:56:01 -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 IAA24280 for ; Wed, 8 Feb 2006 08:54:11 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6q02-0005SS-0l for xcon@ietf.org; Wed, 08 Feb 2006 09:08:55 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 34B3AD15; Wed, 8 Feb 2006 14:55:38 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 14:55:37 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 14:55:37 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Conference Control Date: Wed, 8 Feb 2006 14:55:36 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYozcVwZVa4do1zQOuU5v76voyC1QD6Bt1Q From: "Oscar Novo \(JO/LMF\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 08 Feb 2006 13:55:37.0835 (UTC) FILETIME=[57163BB0:01C62CB7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Hi Henning, No, I haven=B4t measured the latency and maybe it is not a problem as = Brian said in a previous email but I think we have to take in account = several things about the compression (compression efficience, latency, = CPU processing for small devices, and so on) if you are thinking to use = compression in your protocol. =20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 3. helmikuuta 2006 16:28 To: Oscar Novo (JO/LMF) Cc: Cullen Jennings; Chris Boulton; Adam Roach; ajohnston@tello.com; = XCON-IETF Subject: Re: [XCON] Conference Control Have you actually measured the latency for compression? We're probably = talking 2-3 ms here, based on my experience. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Feb 08 09:24: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 1F6qFW-0002X5-Aj; Wed, 08 Feb 2006 09:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qFT-0002Uf-KR for xcon@megatron.ietf.org; Wed, 08 Feb 2006 09:24: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 JAA26376 for ; Wed, 8 Feb 2006 09:23:05 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6qS0-0006Tq-MX for xcon@ietf.org; Wed, 08 Feb 2006 09:37:49 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81C73EFE; Wed, 8 Feb 2006 15:24:33 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 15:24:33 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 15:24:33 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Conference Control Date: Wed, 8 Feb 2006 15:24:32 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAM1WFtAAC/nS4AAXXOIQ From: "Oscar Novo \(JO/LMF\)" To: "Sean Olson" , "Burger, Eric" X-OriginalArrivalTime: 08 Feb 2006 14:24:33.0286 (UTC) FILETIME=[617F0A60:01C62CBB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 Just as an example, the Henning's SOAP proposal = (http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-00= .html) has three examples in section 6. If we count the words in every = example and the URIS, we have the following: Number of words Number of URIs %of URIS = -------------------------------------------------------- 1 example 50 5 10% 2 example 10 0 0% 3 example 15 1 6.6% The number of URIs per operation is quite small compared with the amount = of text. If you still think that URIs are a big problem to create small = operations. Always we can create "relative" URIs in 8 bits that the = conference server can handle. Something like: "1" -> "sip:muyser3241@extension.provider.example.net" "2" -> "sips:conf223@example.com" ... Actually the administrator of the network doesn=B4t care about the uri = of a user, media, or floor. It only needs a way to identify this user, = media, floor... inside his conference server and it should be the same = to identify one user as a = "sip:muyser3241@extension.provider.example.net" or as a user "1". Oscar -----Original Message----- From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Tuesday, February 07, 2006 6:58 PM To: Sean Olson Cc: XCON-IETF Subject: RE: [XCON] Conference Control Most of these commands have a URI. Last time I looked, URI's were = 8-bits per character octets. Octets are binary. Octets are huge. Ask anyone who lived through the H.248 wars. Binary encodings ranged = from 10% smaller than text to 3% larger. Transport compression = effectively brought the PDU's to the same size. Why? Because the big = win is not to say "DELETE CONFERENCE" in 3 bits but to be able to say = "sip:muyser3241@extension.provider.example.net" in 8 bits. You can = create a complex protocol that generates and hands around handles, or = you can use a simple protocol, take the TLS library that is on the = handset, and get the compression free.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, = obviously, apply to conferences with other media types as well. You'll = also notice that most of the parameters to these would be strings where = binary encoding won't help. These are also not as time sensitive as = other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, = but there are sidebars. Sidebar is "media" control - who sees what you = type. You create a sidebar - that's in the noise part. You then send messages = inside the sidebar or in the main conference. It's an interesting = difference between audio/video conferences and IM conferences; with = audio/video, you don't send to a "channel", you send a control message = to change what we do with a fixed channel. Might want to think about = making IM work that way for consistency. I think Aki would have some = misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, = over this protocol, are likely to be media control messages, for which = set/get works well, binary encoding works well, and there aren't very = many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- = while those are very important types of media, I hope that we are not = designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more = emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things = like adjusting volume controls, requesting/granting the floor, changing = your view, etc. These are the controls on the mixer. Then will come = the functions for managing sidebars, also mostly mixer controls. Then, = down in the couple percent range, will be the creation and upper = management stuff. The design center for the protocol should be mixer controls. They are = mostly short and sweet (set this control to this value). The other = stuff is really in the noise. This observation is one reason I like end = system mixing. It also argues for a BFCP-like approach if centralized = mixers are the norm. It also occurs to me, as I think of it, that we either want to use a = learned dictionary compression system for the restricted bandwidth = control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over = again, or we assign a handle to the URI and send that. If I want to = adjust my volume control for your speech, "your" is indentified in the = protocol as either your URI that I learn from the roster, or a handle = for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion = of real-time needs, this appears far less of an issue for creating and = managing conferences. In addition, many of the items that needed for = conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant = improvements in effective length, particularly once compression has been = applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Feb 08 10:55:48 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 1F6rfY-0001xx-MZ; Wed, 08 Feb 2006 10:55:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rfV-0001xB-Hm for xcon@megatron.ietf.org; Wed, 08 Feb 2006 10:55:47 -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 KAA03213 for ; Wed, 8 Feb 2006 10:53:52 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rrv-0001Cj-ML for xcon@ietf.org; Wed, 08 Feb 2006 11:08:38 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by mx2.foretec.com with esmtp (Exim 4.24) id 1F6rfH-0000jG-Q6 for xcon@ietf.org; Wed, 08 Feb 2006 10:55:31 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Feb 2006 07:54:38 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 07:54:38 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 07:54:37 -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); Wed, 8 Feb 2006 07:54:37 -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: Wed, 8 Feb 2006 07:54:35 -0800 Message-ID: In-Reply-To: Thread-Topic: [XCON] Conference Control thread-index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAM1WFtAAC/nS4AAXXOIQAANF2cA= From: "Sean Olson" To: "Oscar Novo \(JO/LMF\)" , "Burger, Eric" X-OriginalArrivalTime: 08 Feb 2006 15:54:37.0301 (UTC) FILETIME=[F68A4A50:01C62CC7] X-Spam-Score: 1.1 (+) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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 >Actually the administrator of the network doesn=B4t care about the uri = of a user, media, or=20 >floor. It only needs a way to identify this user, media, floor... = inside his conference server=20 >and it should be the same to identify one user as a "sip:muyser3241 >@extension.provider.example.net" or as a user "1".=20 Odd.... I'm very curious on what basis you would state this. The admins = I've spoken to are VERY interested in seeing the URI. But I understand = where you are going. Like I said, XML does compress very well. I'll do a = similar analysis for some real world examples from C3P and post that = once I'm done. Cheers, Sean -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Wednesday, February 08, 2006 6:25 AM To: Sean Olson; Burger, Eric Cc: XCON-IETF Subject: RE: [XCON] Conference Control Just as an example, the Henning's SOAP proposal = (http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-00= .html) has three examples in section 6. If we count the words in every = example and the URIS, we have the following: Number of words Number of URIs %of URIS = -------------------------------------------------------- 1 example 50 5 10% 2 example 10 0 0% 3 example 15 1 6.6% The number of URIs per operation is quite small compared with the amount = of text. If you still think that URIs are a big problem to create small = operations. Always we can create "relative" URIs in 8 bits that the = conference server can handle. Something like: "1" -> "sip:muyser3241@extension.provider.example.net" "2" -> "sips:conf223@example.com" ... Actually the administrator of the network doesn=B4t care about the uri = of a user, media, or floor. It only needs a way to identify this user, = media, floor... inside his conference server and it should be the same = to identify one user as a = "sip:muyser3241@extension.provider.example.net" or as a user "1". Oscar -----Original Message----- From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Tuesday, February 07, 2006 6:58 PM To: Sean Olson Cc: XCON-IETF Subject: RE: [XCON] Conference Control Most of these commands have a URI. Last time I looked, URI's were = 8-bits per character octets. Octets are binary. Octets are huge. Ask anyone who lived through the H.248 wars. Binary encodings ranged = from 10% smaller than text to 3% larger. Transport compression = effectively brought the PDU's to the same size. Why? Because the big = win is not to say "DELETE CONFERENCE" in 3 bits but to be able to say = "sip:muyser3241@extension.provider.example.net" in 8 bits. You can = create a complex protocol that generates and hands around handles, or = you can use a simple protocol, take the TLS library that is on the = handset, and get the compression free.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, = obviously, apply to conferences with other media types as well. You'll = also notice that most of the parameters to these would be strings where = binary encoding won't help. These are also not as time sensitive as = other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, = but there are sidebars. Sidebar is "media" control - who sees what you = type. You create a sidebar - that's in the noise part. You then send messages = inside the sidebar or in the main conference. It's an interesting = difference between audio/video conferences and IM conferences; with = audio/video, you don't send to a "channel", you send a control message = to change what we do with a fixed channel. Might want to think about = making IM work that way for consistency. I think Aki would have some = misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, = over this protocol, are likely to be media control messages, for which = set/get works well, binary encoding works well, and there aren't very = many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- = while those are very important types of media, I hope that we are not = designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more = emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things = like adjusting volume controls, requesting/granting the floor, changing = your view, etc. These are the controls on the mixer. Then will come = the functions for managing sidebars, also mostly mixer controls. Then, = down in the couple percent range, will be the creation and upper = management stuff. The design center for the protocol should be mixer controls. They are = mostly short and sweet (set this control to this value). The other = stuff is really in the noise. This observation is one reason I like end = system mixing. It also argues for a BFCP-like approach if centralized = mixers are the norm. It also occurs to me, as I think of it, that we either want to use a = learned dictionary compression system for the restricted bandwidth = control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over = again, or we assign a handle to the URI and send that. If I want to = adjust my volume control for your speech, "your" is indentified in the = protocol as either your URI that I learn from the roster, or a handle = for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion = of real-time needs, this appears far less of an issue for creating and = managing conferences. In addition, many of the items that needed for = conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant = improvements in effective length, particularly once compression has been = applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Feb 09 02:58:33 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 1F76hF-000686-1d; Thu, 09 Feb 2006 02:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F76h9-00066P-Jg for xcon@megatron.ietf.org; Thu, 09 Feb 2006 02:58:31 -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 CAA26513 for ; Thu, 9 Feb 2006 02:56:34 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F76tf-0004nS-IQ for xcon@ietf.org; Thu, 09 Feb 2006 03:11:28 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1F8214F0031; Thu, 9 Feb 2006 08:57:55 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 08:57:54 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 08:57:54 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Conference Control Date: Thu, 9 Feb 2006 08:57:41 +0100 Message-ID: Thread-Topic: [XCON] Conference Control Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAM1WFtAAC/nS4AAXXOIQAANF2cAAIbXyIA== From: "Oscar Novo \(JO/LMF\)" To: "Sean Olson" , "Burger, Eric" X-OriginalArrivalTime: 09 Feb 2006 07:57:54.0869 (UTC) FILETIME=[88934650:01C62D4E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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 Of course the URI is very important mainly for security issues = (authentication, ...) but for operations like "mute the audio of user = X", "change the display text of user X", and a big number of operations = I don=B4t see the needed to send the "real" URI. It=B4s what I wanted to = say in my last email. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: 8. helmikuuta 2006 17:55 To: Oscar Novo (JO/LMF); Burger, Eric Cc: XCON-IETF Subject: RE: [XCON] Conference Control >Actually the administrator of the network doesn=B4t care about the uri = of=20 >a user, media, or floor. It only needs a way to identify this user,=20 >media, floor... inside his conference server and it should be the same=20 >to identify one user as a "sip:muyser3241 = @extension.provider.example.net" or as a user "1". Odd.... I'm very curious on what basis you would state this. The admins = I've spoken to are VERY interested in seeing the URI. But I understand = where you are going. Like I said, XML does compress very well. I'll do a = similar analysis for some real world examples from C3P and post that = once I'm done. Cheers, Sean -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Wednesday, February 08, 2006 6:25 AM To: Sean Olson; Burger, Eric Cc: XCON-IETF Subject: RE: [XCON] Conference Control Just as an example, the Henning's SOAP proposal = (http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-00= .html) has three examples in section 6. If we count the words in every = example and the URIS, we have the following: Number of words Number of URIs %of URIS = -------------------------------------------------------- 1 example 50 5 10% 2 example 10 0 0% 3 example 15 1 6.6% The number of URIs per operation is quite small compared with the amount = of text. If you still think that URIs are a big problem to create small = operations. Always we can create "relative" URIs in 8 bits that the = conference server can handle. Something like: "1" -> "sip:muyser3241@extension.provider.example.net" "2" -> "sips:conf223@example.com" ... Actually the administrator of the network doesn=B4t care about the uri = of a user, media, or floor. It only needs a way to identify this user, = media, floor... inside his conference server and it should be the same = to identify one user as a = "sip:muyser3241@extension.provider.example.net" or as a user "1". Oscar -----Original Message----- From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Tuesday, February 07, 2006 6:58 PM To: Sean Olson Cc: XCON-IETF Subject: RE: [XCON] Conference Control Most of these commands have a URI. Last time I looked, URI's were = 8-bits per character octets. Octets are binary. Octets are huge. Ask anyone who lived through the H.248 wars. Binary encodings ranged = from 10% smaller than text to 3% larger. Transport compression = effectively brought the PDU's to the same size. Why? Because the big = win is not to say "DELETE CONFERENCE" in 3 bits but to be able to say = "sip:muyser3241@extension.provider.example.net" in 8 bits. You can = create a complex protocol that generates and hands around handles, or = you can use a simple protocol, take the TLS library that is on the = handset, and get the compression free.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, = obviously, apply to conferences with other media types as well. You'll = also notice that most of the parameters to these would be strings where = binary encoding won't help. These are also not as time sensitive as = other media control commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, = but there are sidebars. Sidebar is "media" control - who sees what you = type. You create a sidebar - that's in the noise part. You then send messages = inside the sidebar or in the main conference. It's an interesting = difference between audio/video conferences and IM conferences; with = audio/video, you don't send to a "channel", you send a control message = to change what we do with a fixed channel. Might want to think about = making IM work that way for consistency. I think Aki would have some = misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, = over this protocol, are likely to be media control messages, for which = set/get works well, binary encoding works well, and there aren't very = many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- = while those are very important types of media, I hope that we are not = designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more = emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things = like adjusting volume controls, requesting/granting the floor, changing = your view, etc. These are the controls on the mixer. Then will come = the functions for managing sidebars, also mostly mixer controls. Then, = down in the couple percent range, will be the creation and upper = management stuff. The design center for the protocol should be mixer controls. They are = mostly short and sweet (set this control to this value). The other = stuff is really in the noise. This observation is one reason I like end = system mixing. It also argues for a BFCP-like approach if centralized = mixers are the norm. It also occurs to me, as I think of it, that we either want to use a = learned dictionary compression system for the restricted bandwidth = control channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over = again, or we assign a handle to the URI and send that. If I want to = adjust my volume control for your speech, "your" is indentified in the = protocol as either your URI that I learn from the roster, or a handle = for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion = of real-time needs, this appears far less of an issue for creating and = managing conferences. In addition, many of the items that needed for = conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant = improvements in effective length, particularly once compression has been = applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Feb 09 08:54: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 1F7CG0-0001wm-Uz; Thu, 09 Feb 2006 08:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CFs-0001tP-8S for xcon@megatron.ietf.org; Thu, 09 Feb 2006 08:54:46 -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 IAA22850 for ; Thu, 9 Feb 2006 08:52:45 -0500 (EST) Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7CST-0000Au-UI for xcon@ietf.org; Thu, 09 Feb 2006 09:07:42 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F7CFB-0002Wy-AR; Thu, 09 Feb 2006 07:53:57 -0600 From: "Brian Rosen" To: "'Oscar Novo \(JO/LMF\)'" , "'Sean Olson'" , "'Burger, Eric'" Subject: RE: [XCON] Conference Control Date: Thu, 9 Feb 2006 08:51:36 -0500 Message-ID: <03a501c62d7f$f4224160$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 In-Reply-To: Thread-Index: AcYoY2Ij7vNa6bWRS++ca1r7StMZRwAWu3MwAAx8hVAAAIflsAAA+4QQAM1WFtAAC/nS4AAXXOIQAANF2cAAIbXyIAAMdY/w X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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: 1.1 (+) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Content-Transfer-Encoding: quoted-printable Cc: 'XCON-IETF' 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 This highlights the differences between my point of view and Sean's. I view simple conferences as not needing xcon. Creating conferences, negotiating media, establishing connections to the mixer, finding out = who is in the conference, and even local operations like a local mute-yourself = does not need anything beyond SIP and the conference package. If you need xcon, you have a highly functional client, and you want = highly interactive operations with the conference server. I think that is = mostly in the domain of mixer state changes, which includes floor related operations. I don't think we need to be particularly clever in how we, = for example, establish a sidebar. I think we need to be clever in how a = user manipulates his participation in the sidebar. Since a sidebar has been defined (against my way of thinking) as having its own URI, it's not = even clear to me that you need xcon to create sidebars. As a consequence, I think the idea of having an index of URIs for = membership issues works. It's a shorthand notation, and given sufficiently clever compression you would not need the protocol to be explicit about = shorthand notation, but unless we are going to be so clever about compression = (which I don't think we should), then using an index seems appropriate. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Oscar Novo (JO/LMF) Sent: Thursday, February 09, 2006 2:58 AM To: Sean Olson; Burger, Eric Cc: XCON-IETF Subject: RE: [XCON] Conference Control Of course the URI is very important mainly for security issues (authentication, ...) but for operations like "mute the audio of user = X", "change the display text of user X", and a big number of operations I = don=B4t see the needed to send the "real" URI. It=B4s what I wanted to say in my = last email. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: 8. helmikuuta 2006 17:55 To: Oscar Novo (JO/LMF); Burger, Eric Cc: XCON-IETF Subject: RE: [XCON] Conference Control >Actually the administrator of the network doesn=B4t care about the uri = of=20 >a user, media, or floor. It only needs a way to identify this user,=20 >media, floor... inside his conference server and it should be the same=20 >to identify one user as a "sip:muyser3241 = @extension.provider.example.net" or as a user "1". Odd.... I'm very curious on what basis you would state this. The admins = I've spoken to are VERY interested in seeing the URI. But I understand where = you are going. Like I said, XML does compress very well. I'll do a similar analysis for some real world examples from C3P and post that once I'm = done. Cheers, Sean -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Wednesday, February 08, 2006 6:25 AM To: Sean Olson; Burger, Eric Cc: XCON-IETF Subject: RE: [XCON] Conference Control Just as an example, the Henning's SOAP proposal (http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-00= .ht ml) has three examples in section 6. If we count the words in every = example and the URIS, we have the following: Number of words Number of URIs %of URIS -------------------------------------------------------- 1 example 50 5 10% 2 example 10 0 0% 3 example 15 1 6.6% The number of URIs per operation is quite small compared with the amount = of text. If you still think that URIs are a big problem to create small = operations. Always we can create "relative" URIs in 8 bits that the conference = server can handle. Something like: "1" -> "sip:muyser3241@extension.provider.example.net" "2" -> "sips:conf223@example.com" ... Actually the administrator of the network doesn=B4t care about the uri = of a user, media, or floor. It only needs a way to identify this user, media, floor... inside his conference server and it should be the same to = identify one user as a "sip:muyser3241@extension.provider.example.net" or as a = user "1". Oscar -----Original Message----- From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Tuesday, February 07, 2006 6:58 PM To: Sean Olson Cc: XCON-IETF Subject: RE: [XCON] Conference Control Most of these commands have a URI. Last time I looked, URI's were = 8-bits per character octets. Octets are binary. Octets are huge. Ask anyone who lived through the H.248 wars. Binary encodings ranged = from 10% smaller than text to 3% larger. Transport compression effectively brought the PDU's to the same size. Why? Because the big win is not to = say "DELETE CONFERENCE" in 3 bits but to be able to say "sip:muyser3241@extension.provider.example.net" in 8 bits. You can = create a complex protocol that generates and hands around handles, or you can use = a simple protocol, take the TLS library that is on the handset, and get = the compression free.=20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Sean Olson Sent: Friday, February 03, 2006 2:20 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control Sure, let's start with IM. I can see the need for the following: - Create Conference - Add User - Delete/Eject User - End Conference - Create Sidebar - End Sidebar - Move User to Sidebar - "Mute"/"Unmute" User I don't consider any of these noise. They are all critical. And, = obviously, apply to conferences with other media types as well. You'll also notice = that most of the parameters to these would be strings where binary encoding = won't help. These are also not as time sensitive as other media control = commands might be.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, February 03, 2006 10:55 AM To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control All right, then let's talk about an IM conference. Most of them, once established, don't do anything except send messages, = but there are sidebars. Sidebar is "media" control - who sees what you = type. You create a sidebar - that's in the noise part. You then send messages inside the sidebar or in the main conference. It's an interesting difference between audio/video conferences and IM conferences; with audio/video, you don't send to a "channel", you send a control message = to change what we do with a fixed channel. Might want to think about = making IM work that way for consistency. I think Aki would have some = misgivings... Anyway, what other messages would you expect? I'll stick with my prediction; 90% of messages sent, in the aggregate, = over this protocol, are likely to be media control messages, for which = set/get works well, binary encoding works well, and there aren't very many interesting special purpose methods. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Friday, February 03, 2006 1:35 PM To: br@brianrosen.net; Henning Schulzrinne; Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: RE: [XCON] Conference Control That's assuming of course that all you care about is audio or video -- = while those are very important types of media, I hope that we are not = designing a system that caters only to audio/video conferencing. The other "noise" you talk about is where I think we need to place more emphasis, not less.=20 =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 4:49 AM To: 'Henning Schulzrinne'; 'Cullen Jennings' Cc: 'Chris Boulton'; 'Adam Roach'; ajohnston@tello.com; 'XCON-IETF' Subject: RE: [XCON] Conference Control If you count messages in a conference, 90% of them will be for things = like adjusting volume controls, requesting/granting the floor, changing your view, etc. These are the controls on the mixer. Then will come the functions for managing sidebars, also mostly mixer controls. Then, down = in the couple percent range, will be the creation and upper management = stuff. The design center for the protocol should be mixer controls. They are mostly short and sweet (set this control to this value). The other = stuff is really in the noise. This observation is one reason I like end system mixing. It also argues for a BFCP-like approach if centralized mixers = are the norm. It also occurs to me, as I think of it, that we either want to use a = learned dictionary compression system for the restricted bandwidth control = channel situations (wireless) or have handles for participants. We're either going to repeatedly be sending the same URI over and over again, or we assign a handle to the URI and send that. If I want to = adjust my volume control for your speech, "your" is indentified in the protocol = as either your URI that I learn from the roster, or a handle for it. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, February 02, 2006 4:24 PM To: Cullen Jennings Cc: Chris Boulton; Adam Roach; ajohnston@tello.com; XCON-IETF Subject: Re: [XCON] Conference Control While floor control, in its push-to-talk usage at least, had some notion = of real-time needs, this appears far less of an issue for creating and = managing conferences. In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. I'd be surprised if a binary approach were to offer significant = improvements in effective length, particularly once compression has been applied. Thus, I don't see the analogy. Cullen Jennings wrote: > On 2/1/06 9:18 AM, "Sean Olson" wrote: >=20 >> I do not however agree that a decision to use a binary encoding for=20 >> floor control necessarily means we should generally be constrained to >> use a binary encoding for conference control. >=20 > I certainly have mixed feelings on this myself. I do think that it=20 > makes a fairly strong argument that we need to at least have one=20 > protocol that supports the functionality and is usable in the same=20 > environment that BFCP was designed for. That does not stop us from=20 > having a second protocol with the same functionality that does not=20 > work in the environment BFCP was designed for. >=20 > I'm pretty sure that I did point this all out back when we approved=20 > BFCP that selecting one of the key protocols before having even a=20 > rough idea on the architecture was going to constrain our options=20 > later and that if we were accepting the BFCP requirements, well we had > to accept them for enough > to do xcon conferences on that sort of device, and that would imply similar > constraints on the other protocols. No one seemed to have a problem=20 > with this back when we did BFCP. Ironically, I was the one of the only > people that had any reservations about BFCP. _______________________________________________ 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 _______________________________________________ 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 Feb 10 18:26:03 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 1F7heM-0004Dg-Vb; Fri, 10 Feb 2006 18:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7heL-0004As-G6 for xcon@megatron.ietf.org; Fri, 10 Feb 2006 18:26:01 -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 SAA12330 for ; Fri, 10 Feb 2006 18:24:16 -0500 (EST) Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7hrP-00063i-LM for xcon@ietf.org; Fri, 10 Feb 2006 18:39:32 -0500 Received: from [172.17.2.251] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k1ANPpdW001659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Feb 2006 17:25:54 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <43ED20FF.60306@nostrum.com> Date: Fri, 10 Feb 2006 17:25:51 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------090309060505050407070102" Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Subject: [XCON] [Fwd: RFC 4353 on A Framework for Conferencing with the Session Initiation Protocol (SIP)] 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 This is a multi-part message in MIME format. --------------090309060505050407070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI: The SIP Conferencing Framework has been published as an RFC. /a --------------090309060505050407070102 Content-Type: message/rfc822; name="RFC 4353 on A Framework for Conferencing with the Session Initiation Protocol(SIP)" Content-Disposition: inline; filename="RFC 4353 on A Framework for Conferencing with the Session Initiation Protocol(SIP)" Return-Path: Received: from nostrum.com ([unix socket]) by shaman.nostrum.com (Cyrus v2.2.12) with LMTPA; Fri, 10 Feb 2006 17:09:50 -0600 X-Sieve: CMU Sieve 2.2 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nostrum.com (8.13.4/8.13.4) with ESMTP id k1AN9aIq001401 for ; Fri, 10 Feb 2006 17:09:39 -0600 (CST) (envelope-from ietf-announce-bounces@ietf.org) 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 1F7hF1-0005NF-TD; Fri, 10 Feb 2006 17:59:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hEz-0005Lb-JS; Fri, 10 Feb 2006 17:59:49 -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 RAA09325; Fri, 10 Feb 2006 17:57:47 -0500 (EST) Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7hRk-0004q1-Nt; Fri, 10 Feb 2006 18:13:03 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id k1AMxNWV031668; Fri, 10 Feb 2006 14:59:23 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id k1AMxNRD031667; Fri, 10 Feb 2006 14:59:23 -0800 Date: Fri, 10 Feb 2006 14:59:23 -0800 Message-Id: <200602102259.k1AMxNRD031667@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Content-Type: text/plain X-Spam-Score: -14.7 (--------------) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: sipping@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4353 on A Framework for Conferencing with the Session Initiation Protocol (SIP) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org Received-SPF: none (shaman.nostrum.com: domain of ietf-announce-bounces@ietf.org does not designate permitted sender hosts) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on shaman.nostrum.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A new Request for Comments is now available in online RFC libraries. RFC 4353 Title: A Framework for Conferencing with the Session Initiation Protocol (SIP) Author: J. Rosenberg Status: Informational Date: February 2006 Mailbox: jdrosen@cisco.com Pages: 29 Characters: 67405 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-conferencing-framework-05.txt URL: http://www.rfc-editor.org/rfc/rfc4353.txt The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP\'s usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... --418255e937f94b7b3e6ab12808e0d30d A new Request for Comments is now available in online RFC libraries. RFC 4353 Title: A Framework for Conferencing with the Session Initiation Protocol (SIP) Author: J. Rosenberg Status: Informational Date: February 2006 Mailbox: jdrosen@cisco.com Pages: 29 Characters: 67405 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-conferencing-framework-05.txt URL: http://www.rfc-editor.org/rfc/rfc4353.txt The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP\'s usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------090309060505050407070102 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 --------------090309060505050407070102-- From xcon-bounces@ietf.org Sun Feb 26 15:13:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDSGt-0002yf-PN; Sun, 26 Feb 2006 15:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDSGs-0002xc-Il for xcon@ietf.org; Sun, 26 Feb 2006 15:13:34 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDSGp-0005Oc-95 for xcon@ietf.org; Sun, 26 Feb 2006 15:13:34 -0500 Received: from [192.168.0.102] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k1QKDSDN015202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2006 14:13:29 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44020BE3.1050300@nostrum.com> Date: Sun, 26 Feb 2006 14:13:23 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Alan Johnston Subject: [XCON] XCON Agenda Requests 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: , Errors-To: xcon-bounces@ietf.org [as chair] Anyone who would like agenda time during XCON at the upcoming 65th IETF meeting, please send me and Alan an email by Wednesday, March 8th; include a draft name and an approximate amount of time that you believe discussion will take. Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Feb 27 06:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgd9-0001af-D1; Mon, 27 Feb 2006 06:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgd8-0001aa-LU for xcon@ietf.org; Mon, 27 Feb 2006 06:33:30 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDgd7-0006hM-40 for xcon@ietf.org; Mon, 27 Feb 2006 06:33:30 -0500 Received: from rly12b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12b.srv.mailcontrol.com (MailControl) with ESMTP id k1RBXRv3014244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 11:33:27 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly12b.srv.mailcontrol.com (MailControl) id k1RBXRQT014239 for xcon@ietf.org; Mon, 27 Feb 2006 11:33:27 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 k1RBXQ4S014229; Mon, 27 Feb 2006 11:33:27 +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="us-ascii" Subject: RE: [XCON] XCON Agenda Requests Date: Mon, 27 Feb 2006 11:33:26 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78BA0@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] XCON Agenda Requests Thread-Index: AcY7ESQW541+xWAmTpOUBcsXYO/6TAAgA6bg From: "Chris Boulton" To: "Adam Roach" , X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.122 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alan Johnston 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: , Errors-To: xcon-bounces@ietf.org We had an excellent discussion on the Control Protocol recently and if this work is to move forward we just need to bite the bullet and make a decision.=20=20 There are folks ready and waiting to get this work completed but this is a real sticking point for progress. Chris. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 26 February 2006 20:13 To: xcon@ietf.org Cc: Alan Johnston Subject: [XCON] XCON Agenda Requests [as chair] Anyone who would like agenda time during XCON at the upcoming 65th IETF=20 meeting, please send me and Alan an email by Wednesday, March 8th;=20 include a draft name and an approximate amount of time that you believe=20 discussion will take. Thanks. /a _______________________________________________ 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 Mon Feb 27 10:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkGy-0002Hc-BK; Mon, 27 Feb 2006 10:26:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkGw-0002FO-K8 for xcon@ietf.org; Mon, 27 Feb 2006 10:26:50 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkGw-0006L7-9k for xcon@ietf.org; Mon, 27 Feb 2006 10:26:50 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Feb 2006 07:26:49 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 07:26:48 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 07:26:48 -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); Mon, 27 Feb 2006 07:26:48 -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: [XCON] XCON Agenda Requests Date: Mon, 27 Feb 2006 07:26:49 -0800 Message-ID: In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78BA0@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] XCON Agenda Requests Thread-Index: AcY7ESQW541+xWAmTpOUBcsXYO/6TAAgA6bgAAgNmgA= From: "Sean Olson" To: "Chris Boulton" , "Adam Roach" , X-OriginalArrivalTime: 27 Feb 2006 15:26:48.0245 (UTC) FILETIME=[398DCE50:01C63BB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Alan Johnston 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: , Errors-To: xcon-bounces@ietf.org I would second that and add that there are probably a number of sub-decisions that need to be made as well in support of a final decision on the control protocol: 1) Encoding: Binary, Text, or Both? 2) Operations: What is a reasonable list of operations that need to be supported in the first version of the protocol?=20 3) Multimedia: Is this just for audio/video or are we truly building a multimedia capable protocol? 4) Mobile: Is this just for mobile devices or are we truly building an intelligent endpoint capable protocol? 5) Best Practices: What practical implementation experience using BFCP or the conference event package can we leverage while designing the protocol? /sean -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Monday, February 27, 2006 3:33 AM To: Adam Roach; xcon@ietf.org Cc: Alan Johnston Subject: RE: [XCON] XCON Agenda Requests We had an excellent discussion on the Control Protocol recently and if this work is to move forward we just need to bite the bullet and make a decision. =20 There are folks ready and waiting to get this work completed but this is a real sticking point for progress. Chris. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: 26 February 2006 20:13 To: xcon@ietf.org Cc: Alan Johnston Subject: [XCON] XCON Agenda Requests [as chair] Anyone who would like agenda time during XCON at the upcoming 65th IETF meeting, please send me and Alan an email by Wednesday, March 8th; include a draft name and an approximate amount of time that you believe discussion will take. Thanks. /a _______________________________________________ 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