From exim@www1.ietf.org Tue Nov 4 00:27:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15777 for ; Tue, 4 Nov 2003 00:27:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtiX-0000ha-MY for xcon-archive@odin.ietf.org; Tue, 04 Nov 2003 00:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA45R1J7002692 for xcon-archive@odin.ietf.org; Tue, 4 Nov 2003 00:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtiX-0000hL-Id for xcon-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 00:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15769 for ; Tue, 4 Nov 2003 00:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGtiV-0005xH-00 for xcon-web-archive@ietf.org; Tue, 04 Nov 2003 00:26:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGtiU-0005xD-00 for xcon-web-archive@ietf.org; Tue, 04 Nov 2003 00:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtiW-0000h3-Iv; Tue, 04 Nov 2003 00:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtho-0000gi-5s for xcon@optimus.ietf.org; Tue, 04 Nov 2003 00:26:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15758 for ; Tue, 4 Nov 2003 00:26:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGthl-0005wy-00 for xcon@ietf.org; Tue, 04 Nov 2003 00:26:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AGthl-0005wG-00 for xcon@ietf.org; Tue, 04 Nov 2003 00:26:13 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2003 21:29:40 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA45PcAt023276 for ; Mon, 3 Nov 2003 21:25:39 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-536.cisco.com [10.21.98.24]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJP69116; Mon, 3 Nov 2003 21:25:38 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 03 Nov 2003 21:25:37 -0800 From: Cullen Jennings To: XCON-IETF Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Concerns about mahy-xcon-media-policy-control Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm concerned that it will be incredibly difficult to build clients that read the current media flow graph and can decided what needs to be changed to perform some operation. I'm also concerted it will be very difficult to build media processors that receive some graph and understand what they need to actual do on the DSPs in a way that is efficient on the DSP resources. Let me give an example. Alice has phoned a call center and is in a conference that includes a call center agent Bob. Bob has conference in a third party, called Carla, that validates that Alice said something was ok to Bob. Bob supervisor, Doug, is listening to the call and can whisper to Bob but currently has himself muted. A recording system is recording everything Bob hears (including the whisper) and another recording system monitor system records the stuff Carla hears and says. Carla's supervisor, Zoe, joins the call and tries to form a sidebar with Carla and Bob but Doug would still need to hear this sidebar since he hears everything Bob hears. There are an infinite number of ways of forming a media graph that does this conference. I have a hard time figuring out how Zoe's client is going to get the current media graph and figure out what change it needs to make to this media graph to form the sidebar and not violate the other constraints about the what the recording systems need to record. I don't even know how Zoe's client is going to present a user interface for what it can change about this conference. Let's say that it did figure this all out and sent back a new media graph. This new media graph needs to be run on a DSP platform that has several DSPs. There are constraints to what can be cascaded. There are constraints on how much can be run on a single DSP. There are other conferences running on the same DSPs at the same time. There is highly optimized code for some common situations. I don't know how the media graph is going to be compiled into a highly optimized version of the conference that takes optimal use of the DSP and does not violate any of the constraints. I worked on a compiler for a data flow language that ran on a VLIW processor in a past life. The state of the art in data flow optimizations is not all that great. It's not that any of this is impossible, it's just that it seems very hard to implement. Perhaps I am just being dense and not seeing how all of this would be done. I think I need some convincing that either 1) it actually fairly easy to do or 2) it's only hard in really weird cases and we don't care about those. I would like to hear from other people that might actually implement such a system on how hard it would be and what tweaks could be made that make it simpler. I was initially fairly keen on media graphs as a way of describing conferences but the more I think about implementing them, the less convinced I am that they are practical. Cullen _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 4 04:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06006 for ; Tue, 4 Nov 2003 04:47:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxmE-0005XD-O4 for xcon-archive@odin.ietf.org; Tue, 04 Nov 2003 04:47:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA49l6mw021269 for xcon-archive@odin.ietf.org; Tue, 4 Nov 2003 04:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxmD-0005Wy-F0 for xcon-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 04:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06001 for ; Tue, 4 Nov 2003 04:46:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxmA-0001wH-00 for xcon-web-archive@ietf.org; Tue, 04 Nov 2003 04:47:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGxm9-0001wE-00 for xcon-web-archive@ietf.org; Tue, 04 Nov 2003 04:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxm9-0005Wg-LU; Tue, 04 Nov 2003 04:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxle-0005W1-DP for xcon@optimus.ietf.org; Tue, 04 Nov 2003 04:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05998 for ; Tue, 4 Nov 2003 04:46:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxlb-0001wA-00 for xcon@ietf.org; Tue, 04 Nov 2003 04:46:27 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AGxla-0001vf-00 for xcon@ietf.org; Tue, 04 Nov 2003 04:46:26 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hA49jqp7027347 for ; Tue, 4 Nov 2003 10:45:52 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hA49jpSH027344 for ; Tue, 4 Nov 2003 10:45:51 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hA49jop7027342; Tue, 04 Nov 2003 10:45:51 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9517614D4F; Tue, 4 Nov 2003 10:09:18 +0100 (CET) Date: Tue, 04 Nov 2003 10:45:49 +0100 From: Marcus Brunner Reply-To: Marcus Brunner To: Cullen Jennings Cc: XCON-IETF Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control Message-ID: <876971.1067942749@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen, I agree, your example scarce me as well. I don't think media graphs are helpful in most of the cases. Naturally, there are some very specific case where it might make sense. Marcus --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings wrote: > > I'm concerned that it will be incredibly difficult to build clients that > read the current media flow graph and can decided what needs to be changed > to perform some operation. I'm also concerted it will be very difficult to > build media processors that receive some graph and understand what they > need to actual do on the DSPs in a way that is efficient on the DSP > resources. > > Let me give an example. Alice has phoned a call center and is in a > conference that includes a call center agent Bob. Bob has conference in a > third party, called Carla, that validates that Alice said something was ok > to Bob. Bob supervisor, Doug, is listening to the call and can whisper to > Bob but currently has himself muted. A recording system is recording > everything Bob hears (including the whisper) and another recording system > monitor system records the stuff Carla hears and says. Carla's supervisor, > Zoe, joins the call and tries to form a sidebar with Carla and Bob but > Doug would still need to hear this sidebar since he hears everything Bob > hears. > > There are an infinite number of ways of forming a media graph that does > this conference. > > I have a hard time figuring out how Zoe's client is going to get the > current media graph and figure out what change it needs to make to this > media graph to form the sidebar and not violate the other constraints > about the what the recording systems need to record. I don't even know > how Zoe's client is going to present a user interface for what it can > change about this conference. > > Let's say that it did figure this all out and sent back a new media graph. > This new media graph needs to be run on a DSP platform that has several > DSPs. There are constraints to what can be cascaded. There are constraints > on how much can be run on a single DSP. There are other conferences > running on the same DSPs at the same time. There is highly optimized code > for some common situations. > > I don't know how the media graph is going to be compiled into a highly > optimized version of the conference that takes optimal use of the DSP and > does not violate any of the constraints. I worked on a compiler for a data > flow language that ran on a VLIW processor in a past life. The state of > the art in data flow optimizations is not all that great. > > It's not that any of this is impossible, it's just that it seems very hard > to implement. Perhaps I am just being dense and not seeing how all of this > would be done. I think I need some convincing that either 1) it actually > fairly easy to do or 2) it's only hard in really weird cases and we don't > care about those. I would like to hear from other people that might > actually implement such a system on how hard it would be and what tweaks > could be made that make it simpler. > > I was initially fairly keen on media graphs as a way of describing > conferences but the more I think about implementing them, the less > convinced I am that they are practical. > > Cullen > > > > > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 4 15:53:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05136 for ; Tue, 4 Nov 2003 15:53:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8Aj-000472-JV for xcon-archive@odin.ietf.org; Tue, 04 Nov 2003 15:53:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Kr5rm015802 for xcon-archive@odin.ietf.org; Tue, 4 Nov 2003 15:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8Aj-00046U-Ez for xcon-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 15:53:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05128 for ; Tue, 4 Nov 2003 15:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH8Ae-000597-00 for xcon-web-archive@ietf.org; Tue, 04 Nov 2003 15:53:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH8Ae-000594-00 for xcon-web-archive@ietf.org; Tue, 04 Nov 2003 15:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8Af-00046H-8h; Tue, 04 Nov 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8AM-00045U-LU for xcon@optimus.ietf.org; Tue, 04 Nov 2003 15:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05114 for ; Tue, 4 Nov 2003 15:52:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH8AL-00058Q-00 for xcon@ietf.org; Tue, 04 Nov 2003 15:52:41 -0500 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1AH8AK-00057o-00 for xcon@ietf.org; Tue, 04 Nov 2003 15:52:40 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HNU007M2HXZXQ@firewall.wcom.com> for xcon@ietf.org; Tue, 04 Nov 2003 20:51:36 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HNU00C01HORNY@pmismtp02.wcomnet.com>; Tue, 04 Nov 2003 20:51:35 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.104.183]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HNU00BHWHWZW2@pmismtp02.wcomnet.com>; Tue, 04 Nov 2003 20:51:01 +0000 (GMT) Date: Tue, 04 Nov 2003 14:50:57 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20031104144627.02a25a18@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] Draft Agenda for IETF-58 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , All, Adam and I have finished the draft agenda for next week. If you see any problems or if we somehow missed your agenda request, email myself and Adam right away. Thanks, Alan Johnston co-chair sip:alan@sipstation.com - - - - WEDNESDAY, November 12, 2003 1530-1730 Afternoon Sessions II Salon A INT l2vpn Layer 2 Virtual Private Networks WG Salon C INT nemo Network Mobility WG * Salon F IRTF ans Ad hoc Network Scaling Salon D OPS v6ops IPv6 Operations WG * Salon E SEC sbsm Session Based Security Model for SNMPv3 BOF Salon B TSV xcon Centralized Conferencing WG - Agenda bash (5 minutes) - Milestone review/discussion (10 minutes) (includes status of draft-even-xcon-conference-scenarios-00.txt) - Floor Control (25 minutes) 15 minutes: Marcus Brunner/draft-brunner-xcon-fc-issues-00.txt 10 minutes: TBD/draft-koskelainen-xcon-floor-control-req-00.txt - Conference Policy Control Protocol (CPCP) Requirements/Protocol (35 minutes) 20 minutes: Hisham Khartabil/draft-koskelainen-xcon-cpcp-reqs-01.txt draft-koskelainen-xcon-xcap-cpcp-usage-01.txt 15 minutes: Status of other drafts draft-levin-xcon-cpcp-00.txt - Media Policy Control Protocol (MPCP) Requirements/Protocol (45 minutes) 25 minutes: Rohan Mahy/draft-mahy-xcon-media-policy-control-00.txt draft-even-xcon-media-policy-requirements-00.txt 20 minutes: Cullen Jennings/Parametric Media Templates (no draft) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Nov 5 06:30:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01150 for ; Wed, 5 Nov 2003 06:30:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLrQ-0002AZ-0j for xcon-archive@odin.ietf.org; Wed, 05 Nov 2003 06:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5BU3ln008335 for xcon-archive@odin.ietf.org; Wed, 5 Nov 2003 06:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLrP-0002AM-Sv for xcon-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 06:30:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01070 for ; Wed, 5 Nov 2003 06:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLrL-0001cX-00 for xcon-web-archive@ietf.org; Wed, 05 Nov 2003 06:29:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHLrL-0001cT-00 for xcon-web-archive@ietf.org; Wed, 05 Nov 2003 06:29:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLrO-00027S-KF; Wed, 05 Nov 2003 06:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLqy-00026i-SO for xcon@optimus.ietf.org; Wed, 05 Nov 2003 06:29:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01054 for ; Wed, 5 Nov 2003 06:29:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLqu-0001c7-00 for xcon@ietf.org; Wed, 05 Nov 2003 06:29:32 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHLqs-0001c3-00 for xcon@ietf.org; Wed, 05 Nov 2003 06:29:30 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by manatick with esmtp (Exim 4.24) id 1AHLqj-0006UY-JA for xcon@ietf.org; Wed, 05 Nov 2003 06:29:21 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Nov 2003 13:27:49 +0200 Message-ID: From: "Even, Roni" To: XCON-IETF Subject: RE: [XCON] Comments on draft-evan-xcon-conference-scenarios-00 Date: Wed, 5 Nov 2003 13:27:48 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Eric, Sorry for the late response. My comments are in line ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Monday, July 14, 2003 5:10 PM To: IETF XCON Discussion List (E-mail) Subject: [XCON] Comments on draft-evan-xcon-conference-scenarios-00 2. Conference Scenarios What is meant by the UA providing DTMF tones. Does this mean "provide DTMF tones", e.g., generate in-band tone? What about compressed codecs? Does this mean "RFC2833"? If so, the data is going to the wrong place. Does this mean "KPML"? If so, it is bending the use of KPML into the IVR realm, which KPML is explicitly not suited for. [RE] The expectation is that the UA will be able to provide DTMF. This cab be either by actual tones or using RFC2833. Since we are addressing centralized conferences the media channel that carries the tones or payload will get to the mixer who will pass it to the focus to handle it. Since this is the simple UA then he is not expected to support other methods for signaling DTMF. I think that the major thing here is that SIP endpoint will enable sending DTMF (some do not capture the key press at all during the call) 2.1 Ad-hoc conference What is a "number" in SIP? This paragraph refers to calling and called number. Do you mean Request-URI and a From or Contact URI? [RE] Thanks, I will change my text 3.5 Advanced conference features Is it likely that participants will be manipulating the mix directly? See my rant on who might do what with whom. [RE] - I will expect that a user that has the right authorization will be able to manipulate the mix. This can be to force a specific view, to change the layout. Current conferencing bridges allow that using a web based application or by using a "stimulus" application. The work on media policy control will enable such application. The complexity of the protocol is not relevant since a good user interface will make it simple to use. 4.1 Video mixing scenarios Are there any protocol issues here? By definition, an application creates the web page and it deals with the POST. Who needs a protocol? Certainly not the user agent. [RE] The media policy control protocol is being defined to enable control of video mix regardless of the conference bridge manufacturer. The user will control the mix either by a web based application or an end point manufacturer will decide to support the protocol directly from the end point. I think my text has both options. 4.3 Conference Sidebar scenario Will the user really set the main mix gain? Will they specify it in dB, 1-10, 1-100? What about AGC? [RE] This is a good question, I am not sure either but that was an input I got from a group member (I think Brian Rosen) Isn't the behavior of moving someone into the sidebar application-specific? It should be. Some just dump people in, others announce them to the sidebar, others do a tone. I don't think we should be standardizing (or creating protocols that enable) only one way of doing it. By the way, specifying all of the options presented in this scenario virtually requires at least a 2D GUI. See 4.1. [RE] The purpose of the draft is to describe typical application scenarios. We then must see if we can achieve those scenarios using the designed architecture and protocols. The user interface and the capabilities of a specific implementation is up to the developer. We intend to see that application developer can develop such applications not by proprietary APIs. 4.5 Presentation and QA session The scenario states the panel members are identified. Note that often, all listeners are identified to the panel members but not to each other, until (optionally) they get the floor ("now speaking..."). [RE] This is an application issue , the protocol should enable it. The application can learn who is in the conference using the conference package. The rest is up to what scenario the application developer will want to expose to the user. _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Nov 5 07:31:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03058 for ; Wed, 5 Nov 2003 07:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMoR-0005Mj-FT for xcon-archive@odin.ietf.org; Wed, 05 Nov 2003 07:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5CV3OY020619 for xcon-archive@odin.ietf.org; Wed, 5 Nov 2003 07:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMoR-0005MU-AU for xcon-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 07:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03032 for ; Wed, 5 Nov 2003 07:30:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMoQ-0002th-00 for xcon-web-archive@ietf.org; Wed, 05 Nov 2003 07:31:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHMoQ-0002te-00 for xcon-web-archive@ietf.org; Wed, 05 Nov 2003 07:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMoQ-0005M8-9h; Wed, 05 Nov 2003 07:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMoG-0005LX-GA for xcon@optimus.ietf.org; Wed, 05 Nov 2003 07:30:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03028 for ; Wed, 5 Nov 2003 07:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMoF-0002tQ-00 for xcon@ietf.org; Wed, 05 Nov 2003 07:30:51 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHMoD-0002tL-00 for xcon@ietf.org; Wed, 05 Nov 2003 07:30:50 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by manatick with esmtp (Exim 4.24) id 1AHMoC-0008WH-27 for xcon@ietf.org; Wed, 05 Nov 2003 07:30:48 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Nov 2003 14:05:58 +0200 Message-ID: From: "Even, Roni" To: "'Eric Burger'" , XCON-IETF Subject: RE: [XCON] Comments on draft-even-xcon-media-policy-requirements- 00 Date: Wed, 5 Nov 2003 14:05:57 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Eric, My comments are inline ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Monday, July 14, 2003 5:10 PM To: IETF XCON Discussion List (E-mail) Subject: [XCON] Comments on draft-even-xcon-media-policy-requirements-00 The architecture section (4) states, "The focus uses the media policy to determine the proper configuration of the mixers." Does this fall within the proposed charter? [RE] this is according to the framework draft. It says that the data is in the media policy but the protocol between the mixer and the media policy server is out of scope. REQ-GP1 What is the use case for endpoints arbitrarily specifying plumbing? [RE] One example: In a 5-way conference I may chose to see only the speaker on the full screen while another participant may wish to see all the other participants in a 2x2 view. REQ-GP3 What is the use case here? Are we really saying that it is has to be possible to add a leg to the mix? If so, say so. [RE] The general section applies both to audio and video. GP-3 means for audio to change the mix level and for video it means to change the layout for example from 2x2 to 3x3 REQ-GP8 I don't understand this at all. Can we restate it? [RE] The meaning to enable specifying how many different mixes will be in the conference. Do we have one audio mix and one video mix that all participants get, does each participant get his own audio mix and all see the same video. Maybe you can help me with the text? REQ-GP9 Is the idea to mix the user's media separately or differently? For example, the user's Camera 1 (room) is always shown while Camera 2 (face) is only shown while speaking? [RE] The example in the text is widely used today in video conferencing. We have two video streams, one is showing the room while the other is coming from a VGA scan converter showing a presentation, we call the room view "people stream" while the other is "content" stream. The content stream is a presentation and is sent to all participants and a token may be used to authorize presentation. In this example the presentation is displayed to all but the people view may change for example showing the presenter at one time and a person asking a question afterwards. So one stream is managed by a token while the other may be voice activated. Another example is the one you mentioned where we have two views coming from the same place and we send them to the other side as two streams. the receiving EP may wish to show one of them but there should be a hint to help it know which stream is the main video stream. 6.2 Is "overlapping windows" a client display issue or a mixing issue, or are there independent windows? [RE] this is a mixing issue, the mixer send a composed stream. So we want to enable overlay. for example we have a 2x2 display but in the middle we have the speaker in an overlay window that hides part of the 2x2 lower layout. REQ-V1 What is the value to a *protocol* to talk about layout? [RE] If I understand the question then if we agree that a participant can define what video composed mix he want to receive and who will be in each mix then the media policy control protocol should enable an application on the user side to specify the layout REQ-V2 Isn't this the definition of a video conferencing application? Who will issue the media policy requests to change things? [RE] The requirement is to able to specify well known mixing scenarios so that you will not need to do complex graphs management for typical video conferencing applications. I think this is in line with the worries about the complexity of the suggested protocol. REQ-V3 Is this for the whole conference or an individual user? [RE] It is for both conference level and participant level but he support of per conference or per participant depends on application, authorization and the number of different video mixes that the managed conference can support. REQ-V4 Is this for the whole conference or an individual user? [RE] Same as REQ-V3 _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Nov 5 18:21:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00463 for ; Wed, 5 Nov 2003 18:21:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWxT-0004RK-UJ for xcon-archive@odin.ietf.org; Wed, 05 Nov 2003 18:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NL3Ea017063 for xcon-archive@odin.ietf.org; Wed, 5 Nov 2003 18:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWxT-0004R8-Mx for xcon-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00440 for ; Wed, 5 Nov 2003 18:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWxQ-0005XO-00 for xcon-web-archive@ietf.org; Wed, 05 Nov 2003 18:21:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHWxQ-0005XL-00 for xcon-web-archive@ietf.org; Wed, 05 Nov 2003 18:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWxS-0004Qf-7x; Wed, 05 Nov 2003 18:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWxB-0004QL-Tx for xcon@optimus.ietf.org; Wed, 05 Nov 2003 18:20:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00419 for ; Wed, 5 Nov 2003 18:20:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWx8-0005XA-00 for xcon@ietf.org; Wed, 05 Nov 2003 18:20:42 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AHWx8-0005Wq-00 for xcon@ietf.org; Wed, 05 Nov 2003 18:20:42 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hA5NKE9c020967 for ; Wed, 5 Nov 2003 18:20:14 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 17:20:12 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865C9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Wed, 5 Nov 2003 17:20:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Meeting Minute Takers: Soliciting volunteers Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , (as chair) Alan and I are soliciting volunteers to take notes during next week's XCON working group meeting. High Priority: Official Minute Taker This simply requires transcription of the major topics of discussion during the session. No "he said/she said" summary is necessary; simply a one line description of each topic, and any conclusions reached. Low Priority: Chat Room Transcriber This task would involve keeping the xcon@ietf.xmpp.org chat room up to date with the current topic. If a participant asks a question in the chat room, this person would be responsible for taking that question to the microphone. Volunteering will earn you the gratitude of the chairs. And warm fuzzies, of course. Please respond to me or Alan if you are willing to take on either of the above tasks. Thank you. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 7 16:21:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08237 for ; Fri, 7 Nov 2003 16:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2T-0001Rm-FI for xcon-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LL5JO005555 for xcon-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2T-0001RF-9H for xcon-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08171 for ; Fri, 7 Nov 2003 16:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2Q-000397-00 for xcon-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2P-00038s-00 for xcon-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2Q-0001Ou-Np; Fri, 07 Nov 2003 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1d-0001Ii-4H for xcon@optimus.ietf.org; Fri, 07 Nov 2003 16:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08130 for ; Fri, 7 Nov 2003 16:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1b-000387-00 for xcon@ietf.org; Fri, 07 Nov 2003 16:20:11 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIE1a-000377-01 for xcon@ietf.org; Fri, 07 Nov 2003 16:20:10 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30260; Fri, 07 Nov 2003 16:26:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Fri, 7 Nov 2003 16:19:35 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F693C@zoe.office.snowshore.com> Thread-Topic: Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 Thread-Index: AcOlbR7Jiv7ln8HwTD2IDZMiQYYIwg== From: "Eric Burger" To: Content-Transfer-Encoding: quoted-printable Subject: [XCON] Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The document doubles many of the requirements by saying: REQ-n It MUST be possible to do X. REQ-(n+1) It MUST be possible to do X to many Y in a single = operation. First question: by single operation, is the goal to reduce the number of = messages (e.g., mass ejecting 100 people using 1 message instead of = 100)? Or, is the goal to have atomic transactions (e.g., if I can't = change all of the privileges for all of the users in the update request, = fail the entire request). If it is the former, why not just state one requirement to be able to = batch requests? That cuts down on the number of requirements by almost = half. If it is the latter, why not just state one requirement to have atomic = multiple operation transactions? The benefit is you can then do both, if that is what the client really = needs. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 7 16:21:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08232 for ; Fri, 7 Nov 2003 16:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2T-0001RE-5W for xcon-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LL5Gu005521 for xcon-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2S-0001Qy-Uk for xcon-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08173 for ; Fri, 7 Nov 2003 16:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2Q-000398-00 for xcon-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2P-000390-00 for xcon-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2R-0001PB-0B; Fri, 07 Nov 2003 16:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1d-0001In-O0 for xcon@optimus.ietf.org; Fri, 07 Nov 2003 16:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08133 for ; Fri, 7 Nov 2003 16:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1b-00038D-00 for xcon@ietf.org; Fri, 07 Nov 2003 16:20:11 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIE1b-000377-00 for xcon@ietf.org; Fri, 07 Nov 2003 16:20:11 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30260; Fri, 07 Nov 2003 16:26:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Fri, 7 Nov 2003 16:19:36 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F693D@zoe.office.snowshore.com> Thread-Topic: Various scopes in draft-brunner-xcon-fc-00 Thread-Index: AcOlbYx4xDIiSwRqSru3Ly4mnrBZ6g== From: "Eric Burger" To: Content-Transfer-Encoding: quoted-printable Subject: [XCON] Various scopes in draft-brunner-xcon-fc-00 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Some interesting things here. Any chance of integrating the new stuff = w/ xcon-floor-contro-req? What does the first requirement (section 4 - "various scopes") mean? _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 7 17:06:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08235 for ; Fri, 7 Nov 2003 16:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2T-0001Rj-E7 for xcon-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LL53f005541 for xcon-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2T-0001RD-62 for xcon-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08180 for ; Fri, 7 Nov 2003 16:20:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2Q-00039F-00 for xcon-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2Q-000396-00 for xcon-web-archive@ietf.org; Fri, 07 Nov 2003 16:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2R-0001PT-9B; Fri, 07 Nov 2003 16:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1e-0001Is-Bw for xcon@optimus.ietf.org; Fri, 07 Nov 2003 16:20:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08136 for ; Fri, 7 Nov 2003 16:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1c-00038I-00 for xcon@ietf.org; Fri, 07 Nov 2003 16:20:12 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIE1b-000377-01 for xcon@ietf.org; Fri, 07 Nov 2003 16:20:12 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30260; Fri, 07 Nov 2003 16:26:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Fri, 7 Nov 2003 16:19:36 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F693E@zoe.office.snowshore.com> Thread-Topic: Comments on draft-ekim-xcon-cpcp-bb-00 Thread-Index: AcOlb302XHlNmkKHQmSBKEgwRsiYWA== From: "Eric Burger" To: Content-Transfer-Encoding: quoted-printable Subject: [XCON] Comments on draft-ekim-xcon-cpcp-bb-00 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable First, I'll staying far away from the = draft-koskelainen-xcon-xcap-cpcp-usage-01.txt debate. However, it is = instructive to look into the "additional" stuff, or even at least see = alternate interpretations of the same stuff (if it is the same stuff -- = I'm not getting into the debate). More discussion of the issues raised = should help the work group produce better documents. Section 3: Why MUST the protocol be XML? There is not reason for this = implementation choice being a requirement. Of course, everyone knows I = would go ballistic if it was ASN.1, but that would be an implementation = choice, not a need. I don't think the document means the focus would ask the CPS for = authentication of participants. Authentication means proving *who* the = client is. The CPS would be needed to decide if the client is = *authorized*. It is probably useful to say the transport protocol = (e.g., http/SOAP, SIP, etc.) would provide the authentication function. Section 6.1: What is the value of specifying static versus dynamic closed = conferences? For example, a client cannot tell the difference between a = closed conference and a conference that has its maximum number of = participants. Either way, a new participant cannot join. How about = making availability to join a separate parameter (if that is useful)? Section 6.1: Does the conference time element say when the conference WILL BE, or = when the conference WAS. The text implies future scheduling. That = could be clearer. Section 7.1.2: Why is conf-name present? If conf-URI is present (mandatory, so it = should be), that is enough to uniquely identify the conference. Adding = conf-name confuses things. For example, what if conf-name does not = match conf-URI? That adds an error condition to handle. Allowing conf-name would make sense if you could identify the conference = to be destroyed by *either* conf-name or conf-URI. However, that adds = another new error condition. I don't think conf-name is necessarily = unique. Thus one would have to handle the "ambiguous name" error = condition. Allowing only conf-URI is so much cleaner. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sat Nov 8 16:06:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27098 for ; Sat, 8 Nov 2003 16:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIaHS-0006Wo-Ui for xcon-archive@odin.ietf.org; Sat, 08 Nov 2003 16:06:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8L62W9025088 for xcon-archive@odin.ietf.org; Sat, 8 Nov 2003 16:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIaHS-0006WZ-QB for xcon-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 16:06:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27094 for ; Sat, 8 Nov 2003 16:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIaHR-0004ks-00 for xcon-web-archive@ietf.org; Sat, 08 Nov 2003 16:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIaHQ-0004kp-00 for xcon-web-archive@ietf.org; Sat, 08 Nov 2003 16:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIaHQ-0006WB-SV; Sat, 08 Nov 2003 16:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIaHN-0006Vu-VO for xcon@optimus.ietf.org; Sat, 08 Nov 2003 16:05:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27088 for ; Sat, 8 Nov 2003 16:05:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIaHM-0004kg-00 for xcon@ietf.org; Sat, 08 Nov 2003 16:05:56 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIaHL-0004kd-00 for xcon@ietf.org; Sat, 08 Nov 2003 16:05:55 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 12529; Sat, 08 Nov 2003 16:12:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Concerns about mahy-xcon-media-policy-control Date: Sat, 8 Nov 2003 16:05:25 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6958@zoe.office.snowshore.com> Thread-Topic: [XCON] Concerns about mahy-xcon-media-policy-control Thread-Index: AcOiuKG4E9P5H7MWTqqT8T4y3+uDlQC71xsQ From: "Eric Burger" To: "XCON-IETF" Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chiming in, I would offer that for the "easy cases", it would be better = to say what we mean. E.g., rather than arbitrary graphs at the RTP/DSP = level, just say, "I want a sidebar" or "record this"? I really don't like the idea of replicating H.284.1 in XML :-) > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Tue, November 04, 2003 4:46 AM > To: Cullen Jennings > Cc: XCON-IETF > Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control >=20 >=20 > Cullen, >=20 > I agree, your example scarce me as well. I don't think media=20 > graphs are=20 > helpful in most of the cases. Naturally, there are some very=20 > specific case=20 > where it might make sense. >=20 > Marcus >=20 > --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings=20 > wrote: >=20 > > > > I'm concerned that it will be incredibly difficult to build=20 > clients that > > read the current media flow graph and can decided what=20 > needs to be changed > > to perform some operation. I'm also concerted it will be=20 > very difficult to > > build media processors that receive some graph and=20 > understand what they > > need to actual do on the DSPs in a way that is efficient on the DSP > > resources. > > > > Let me give an example. Alice has phoned a call center and is in a > > conference that includes a call center agent Bob. Bob has=20 > conference in a > > third party, called Carla, that validates that Alice said=20 > something was ok > > to Bob. Bob supervisor, Doug, is listening to the call and=20 > can whisper to > > Bob but currently has himself muted. A recording system is recording > > everything Bob hears (including the whisper) and another=20 > recording system > > monitor system records the stuff Carla hears and says.=20 > Carla's supervisor, > > Zoe, joins the call and tries to form a sidebar with Carla=20 > and Bob but > > Doug would still need to hear this sidebar since he hears=20 > everything Bob > > hears. > > > > There are an infinite number of ways of forming a media=20 > graph that does > > this conference. > > > > I have a hard time figuring out how Zoe's client is going to get the > > current media graph and figure out what change it needs to=20 > make to this > > media graph to form the sidebar and not violate the other=20 > constraints > > about the what the recording systems need to record. I=20 > don't even know > > how Zoe's client is going to present a user interface for=20 > what it can > > change about this conference. > > > > Let's say that it did figure this all out and sent back a=20 > new media graph. > > This new media graph needs to be run on a DSP platform that=20 > has several > > DSPs. There are constraints to what can be cascaded. There=20 > are constraints > > on how much can be run on a single DSP. There are other conferences > > running on the same DSPs at the same time. There is highly=20 > optimized code > > for some common situations. > > > > I don't know how the media graph is going to be compiled=20 > into a highly > > optimized version of the conference that takes optimal use=20 > of the DSP and > > does not violate any of the constraints. I worked on a=20 > compiler for a data > > flow language that ran on a VLIW processor in a past life.=20 > The state of > > the art in data flow optimizations is not all that great. > > > > It's not that any of this is impossible, it's just that it=20 > seems very hard > > to implement. Perhaps I am just being dense and not seeing=20 > how all of this > > would be done. I think I need some convincing that either=20 > 1) it actually > > fairly easy to do or 2) it's only hard in really weird=20 > cases and we don't > > care about those. I would like to hear from other people that might > > actually implement such a system on how hard it would be=20 > and what tweaks > > could be made that make it simpler. > > > > I was initially fairly keen on media graphs as a way of describing > > conferences but the more I think about implementing them, the less > > convinced I am that they are practical. > > > > Cullen > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. >=20 > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus >=20 >=20 >=20 >=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 From exim@www1.ietf.org Mon Nov 10 09:55:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21729 for ; Mon, 10 Nov 2003 09:55:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDRY-0008IF-K1 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 09:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAEt4N5031858 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 09:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDRY-0008Hl-DD for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 09:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21698 for ; Mon, 10 Nov 2003 09:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDRW-0005UP-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 09:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJDRW-0005UL-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 09:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDRW-0008HR-8F; Mon, 10 Nov 2003 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDRJ-0008Gv-21 for xcon@optimus.ietf.org; Mon, 10 Nov 2003 09:54:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21693 for ; Mon, 10 Nov 2003 09:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDRH-0005UG-00 for xcon@ietf.org; Mon, 10 Nov 2003 09:54:47 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJDRG-0005UB-00 for xcon@ietf.org; Mon, 10 Nov 2003 09:54:46 -0500 Received: from n-pool-3.office (dyn130-111.ietf58.ietf.org [130.129.130.111]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 61EB310378; Mon, 10 Nov 2003 15:59:03 +0100 (CET) Date: Mon, 10 Nov 2003 09:54:22 -0500 From: Marcus Brunner Reply-To: Marcus Brunner To: Eric Burger Cc: xcon@ietf.org Subject: Re: [XCON] Various scopes in draft-brunner-xcon-fc-00 Message-ID: <12797161.1068458061@n-pool-3.office> In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F693D@zoe.office.snowshore.com> References: <4A3384433CE2AB46A63468CB207E209D4F693D@zoe.office.snowshore.com > X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, --On Friday, November 07, 2003 4:19 PM -0500 Eric Burger wrote: > Some interesting things here. Any chance of integrating the new stuff w/ > xcon-floor-contro-req? > sure > What does the first requirement (section 4 - "various scopes") mean? > > Actually there are 2 things concerning the scope. In the first issue of the draft, it about what entities are under one floor's control. Is it per flow (what ever flow means), session, per-application. However, I think this is sort of already included in draft-kosteleinen- e other thing is the group of participant, which can implicitly get the floor./ Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Nov 10 10:58:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26314 for ; Mon, 10 Nov 2003 10:58:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEQV-0004Or-RI for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 10:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFw3fM016898 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 10:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEQV-0004OP-2d for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26269 for ; Mon, 10 Nov 2003 10:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEQS-0006fA-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 10:58:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEQR-0006ez-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 10:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEQS-0004Nd-Rn; Mon, 10 Nov 2003 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEPn-0004Lp-VX for xcon@optimus.ietf.org; Mon, 10 Nov 2003 10:57:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26208 for ; Mon, 10 Nov 2003 10:57:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEPl-0006e1-00 for xcon@ietf.org; Mon, 10 Nov 2003 10:57:17 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJEPk-0006dM-00 for xcon@ietf.org; Mon, 10 Nov 2003 10:57:17 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAFuiAt017589; Mon, 10 Nov 2003 07:56:45 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK30945; Mon, 10 Nov 2003 07:56:43 -0800 (PST) Date: Mon, 10 Nov 2003 07:56:41 -0800 Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "XCON-IETF" To: "Eric Burger" From: Rohan Mahy In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6958@zoe.office.snowshore.com> Message-Id: <79EFBEAC-1396-11D8-B472-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'm sorry that I have not had time to issue a complete response to Cullen's post. However, in response to Eric's comment, I'd just like to understate the main difference between an approach like H.248 and an approach like the one in draft-mahy-xcon-media-policy... In H.248 if you want to mix in a person who has the floor you have to modify the connection parameters every time a different person gets the floor (first Alice, then Bob, the Zach...). In the media policy approach you ask that the logical holder(s) of floor foo are mixed in and the mixer takes care of the rest. We really have a meta issue to settle in XCON about what level of abstraction meets our requirements without being hideously complex. I will try to explain our choices in a balanced way on this issue when I present media policy open issues to XCON on Wednesday. If you'd like to contribute a slide or other material for this discussion, please send me a short mail or find me in Minneapolis. thanks, -rohan On Saturday, November 8, 2003, at 01:05 PM, Eric Burger wrote: > Chiming in, I would offer that for the "easy cases", it would be > better to say what we mean. E.g., rather than arbitrary graphs at the > RTP/DSP level, just say, "I want a sidebar" or "record this"? > > I really don't like the idea of replicating H.284.1 in XML :-) > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: Tue, November 04, 2003 4:46 AM >> To: Cullen Jennings >> Cc: XCON-IETF >> Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control >> >> >> Cullen, >> >> I agree, your example scarce me as well. I don't think media >> graphs are >> helpful in most of the cases. Naturally, there are some very >> specific case >> where it might make sense. >> >> Marcus >> >> --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings >> wrote: >> >>> >>> I'm concerned that it will be incredibly difficult to build >> clients that >>> read the current media flow graph and can decided what >> needs to be changed >>> to perform some operation. I'm also concerted it will be >> very difficult to >>> build media processors that receive some graph and >> understand what they >>> need to actual do on the DSPs in a way that is efficient on the DSP >>> resources. >>> >>> Let me give an example. Alice has phoned a call center and is in a >>> conference that includes a call center agent Bob. Bob has >> conference in a >>> third party, called Carla, that validates that Alice said >> something was ok >>> to Bob. Bob supervisor, Doug, is listening to the call and >> can whisper to >>> Bob but currently has himself muted. A recording system is recording >>> everything Bob hears (including the whisper) and another >> recording system >>> monitor system records the stuff Carla hears and says. >> Carla's supervisor, >>> Zoe, joins the call and tries to form a sidebar with Carla >> and Bob but >>> Doug would still need to hear this sidebar since he hears >> everything Bob >>> hears. >>> >>> There are an infinite number of ways of forming a media >> graph that does >>> this conference. >>> >>> I have a hard time figuring out how Zoe's client is going to get the >>> current media graph and figure out what change it needs to >> make to this >>> media graph to form the sidebar and not violate the other >> constraints >>> about the what the recording systems need to record. I >> don't even know >>> how Zoe's client is going to present a user interface for >> what it can >>> change about this conference. >>> >>> Let's say that it did figure this all out and sent back a >> new media graph. >>> This new media graph needs to be run on a DSP platform that >> has several >>> DSPs. There are constraints to what can be cascaded. There >> are constraints >>> on how much can be run on a single DSP. There are other conferences >>> running on the same DSPs at the same time. There is highly >> optimized code >>> for some common situations. >>> >>> I don't know how the media graph is going to be compiled >> into a highly >>> optimized version of the conference that takes optimal use >> of the DSP and >>> does not violate any of the constraints. I worked on a >> compiler for a data >>> flow language that ran on a VLIW processor in a past life. >> The state of >>> the art in data flow optimizations is not all that great. >>> >>> It's not that any of this is impossible, it's just that it >> seems very hard >>> to implement. Perhaps I am just being dense and not seeing >> how all of this >>> would be done. I think I need some convincing that either >> 1) it actually >>> fairly easy to do or 2) it's only hard in really weird >> cases and we don't >>> care about those. I would like to hear from other people that might >>> actually implement such a system on how hard it would be >> and what tweaks >>> could be made that make it simpler. >>> >>> I was initially fairly keen on media graphs as a way of describing >>> conferences but the more I think about implementing them, the less >>> convinced I am that they are practical. >>> >>> Cullen >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> Phone: +49 (0) 6221 905 11 29 >> Mobile: +49 (0) 163 275 17 43 >> personal home page: http://www.brubers.org/marcus >> >> >> >> >> >> _______________________________________________ >> 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 exim@www1.ietf.org Mon Nov 10 11:27:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28259 for ; Mon, 10 Nov 2003 11:27:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEsX-0006fI-M2 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 11:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGR1Nv025614 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEsX-0006f3-HO for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28228 for ; Mon, 10 Nov 2003 11:26:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEsW-0007N7-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 11:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEsW-0007N4-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 11:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEsW-0006ep-IL; Mon, 10 Nov 2003 11:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEsK-0006eY-Ny for xcon@optimus.ietf.org; Mon, 10 Nov 2003 11:26:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28214 for ; Mon, 10 Nov 2003 11:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEsJ-0007Ml-00 for xcon@ietf.org; Mon, 10 Nov 2003 11:26:47 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AJEsJ-0007MJ-00 for xcon@ietf.org; Mon, 10 Nov 2003 11:26:47 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19602; Mon, 10 Nov 2003 11:26:13 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27249; Mon, 10 Nov 2003 11:26:15 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 11:26:14 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B60A7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: XCON-IETF Subject: RE: [XCON] Concerns about mahy-xcon-media-policy-control Date: Mon, 10 Nov 2003 11:26:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , It is not at all clear to me how you get a 'logical holder of the floor foo' out of the draft. What is that? A stream, a bundle, a component,...? Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Monday, November 10, 2003 10:57 AM > To: Eric Burger > Cc: XCON-IETF > Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control > > > Hi, > > I'm sorry that I have not had time to issue a complete response to > Cullen's post. However, in response to Eric's comment, I'd just like > to understate the main difference between an approach like > H.248 and an > approach like the one in draft-mahy-xcon-media-policy... > > In H.248 if you want to mix in a person who has the floor you have to > modify the connection parameters every time a different > person gets the > floor (first Alice, then Bob, the Zach...). In the media policy > approach you ask that the logical holder(s) of floor foo are mixed in > and the mixer takes care of the rest. > > We really have a meta issue to settle in XCON about what level of > abstraction meets our requirements without being hideously complex. I > will try to explain our choices in a balanced way on this > issue when I > present media policy open issues to XCON on Wednesday. If you'd like > to contribute a slide or other material for this discussion, please > send me a short mail or find me in Minneapolis. > > thanks, > -rohan > > > On Saturday, November 8, 2003, at 01:05 PM, Eric Burger wrote: > > > Chiming in, I would offer that for the "easy cases", it would be > > better to say what we mean. E.g., rather than arbitrary > graphs at the > > RTP/DSP level, just say, "I want a sidebar" or "record this"? > > > > I really don't like the idea of replicating H.284.1 in XML :-) > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: Tue, November 04, 2003 4:46 AM > >> To: Cullen Jennings > >> Cc: XCON-IETF > >> Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control > >> > >> > >> Cullen, > >> > >> I agree, your example scarce me as well. I don't think media > >> graphs are > >> helpful in most of the cases. Naturally, there are some very > >> specific case > >> where it might make sense. > >> > >> Marcus > >> > >> --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings > >> wrote: > >> > >>> > >>> I'm concerned that it will be incredibly difficult to build > >> clients that > >>> read the current media flow graph and can decided what > >> needs to be changed > >>> to perform some operation. I'm also concerted it will be > >> very difficult to > >>> build media processors that receive some graph and > >> understand what they > >>> need to actual do on the DSPs in a way that is efficient > on the DSP > >>> resources. > >>> > >>> Let me give an example. Alice has phoned a call center and is in a > >>> conference that includes a call center agent Bob. Bob has > >> conference in a > >>> third party, called Carla, that validates that Alice said > >> something was ok > >>> to Bob. Bob supervisor, Doug, is listening to the call and > >> can whisper to > >>> Bob but currently has himself muted. A recording system > is recording > >>> everything Bob hears (including the whisper) and another > >> recording system > >>> monitor system records the stuff Carla hears and says. > >> Carla's supervisor, > >>> Zoe, joins the call and tries to form a sidebar with Carla > >> and Bob but > >>> Doug would still need to hear this sidebar since he hears > >> everything Bob > >>> hears. > >>> > >>> There are an infinite number of ways of forming a media > >> graph that does > >>> this conference. > >>> > >>> I have a hard time figuring out how Zoe's client is going > to get the > >>> current media graph and figure out what change it needs to > >> make to this > >>> media graph to form the sidebar and not violate the other > >> constraints > >>> about the what the recording systems need to record. I > >> don't even know > >>> how Zoe's client is going to present a user interface for > >> what it can > >>> change about this conference. > >>> > >>> Let's say that it did figure this all out and sent back a > >> new media graph. > >>> This new media graph needs to be run on a DSP platform that > >> has several > >>> DSPs. There are constraints to what can be cascaded. There > >> are constraints > >>> on how much can be run on a single DSP. There are other > conferences > >>> running on the same DSPs at the same time. There is highly > >> optimized code > >>> for some common situations. > >>> > >>> I don't know how the media graph is going to be compiled > >> into a highly > >>> optimized version of the conference that takes optimal use > >> of the DSP and > >>> does not violate any of the constraints. I worked on a > >> compiler for a data > >>> flow language that ran on a VLIW processor in a past life. > >> The state of > >>> the art in data flow optimizations is not all that great. > >>> > >>> It's not that any of this is impossible, it's just that it > >> seems very hard > >>> to implement. Perhaps I am just being dense and not seeing > >> how all of this > >>> would be done. I think I need some convincing that either > >> 1) it actually > >>> fairly easy to do or 2) it's only hard in really weird > >> cases and we don't > >>> care about those. I would like to hear from other people > that might > >>> actually implement such a system on how hard it would be > >> and what tweaks > >>> could be made that make it simpler. > >>> > >>> I was initially fairly keen on media graphs as a way of describing > >>> conferences but the more I think about implementing them, the less > >>> convinced I am that they are practical. > >>> > >>> Cullen > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> XCON mailing list > >>> XCON@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/xcon > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> Phone: +49 (0) 6221 905 11 29 > >> Mobile: +49 (0) 163 275 17 43 > >> personal home page: http://www.brubers.org/marcus > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 exim@www1.ietf.org Mon Nov 10 12:04:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00456 for ; Mon, 10 Nov 2003 12:04:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFSM-0001nG-Sa for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 12:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAH42Wo006893 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 12:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFSM-0001n6-Nj for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00422 for ; Mon, 10 Nov 2003 12:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFSL-0000Li-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 12:04:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFSL-0000Lc-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 12:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFSL-0001mP-7C; Mon, 10 Nov 2003 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFRO-0001hi-6j for xcon@optimus.ietf.org; Mon, 10 Nov 2003 12:03:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00369 for ; Mon, 10 Nov 2003 12:02:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFRL-0000Kv-00 for xcon@ietf.org; Mon, 10 Nov 2003 12:02:59 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJFRI-0000Kd-00 for xcon@ietf.org; Mon, 10 Nov 2003 12:02:56 -0500 Received: from nismail-w2k02.cisco.com (sjc-vpn4-80.cisco.com [10.21.80.80]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAAH2MrY024448; Mon, 10 Nov 2003 09:02:23 -0800 (PST) Message-Id: <4.3.2.7.2.20031110084440.00b4fc68@VTG-UM-E2K1> X-Sender: nismail@VTG-UM-E2K1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 09:02:21 -0800 To: "Eric Burger" From: Nermeen Ismail Subject: RE: [XCON] Concerns about mahy-xcon-media-policy-control Cc: "XCON-IETF" In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6958@zoe.office.snowshor e.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I would agree that using service semantics in the protocol will make it simpler for specific services (those that were taken into consideration in the design of the protocol). However there will be loss of flexibility that I think is quite important. I will also claim that for easy cases such as creating a standard sidebar the media graphs are quite simple. You create a new audio-mixing collection and then connect streams to its input and output groups. Having said that I think that the current media graph model can be simplified. Maybe we can discuss that in MPLS. nermeen >Chiming in, I would offer that for the "easy cases", it would be better to >say what we mean. E.g., rather than arbitrary graphs at the RTP/DSP >level, just say, "I want a sidebar" or "record this"? > >I really don't like the idea of replicating H.284.1 in XML :-) > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: Tue, November 04, 2003 4:46 AM > > To: Cullen Jennings > > Cc: XCON-IETF > > Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control > > > > > > Cullen, > > > > I agree, your example scarce me as well. I don't think media > > graphs are > > helpful in most of the cases. Naturally, there are some very > > specific case > > where it might make sense. > > > > Marcus > > > > --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings > > wrote: > > > > > > > > I'm concerned that it will be incredibly difficult to build > > clients that > > > read the current media flow graph and can decided what > > needs to be changed > > > to perform some operation. I'm also concerted it will be > > very difficult to > > > build media processors that receive some graph and > > understand what they > > > need to actual do on the DSPs in a way that is efficient on the DSP > > > resources. > > > > > > Let me give an example. Alice has phoned a call center and is in a > > > conference that includes a call center agent Bob. Bob has > > conference in a > > > third party, called Carla, that validates that Alice said > > something was ok > > > to Bob. Bob supervisor, Doug, is listening to the call and > > can whisper to > > > Bob but currently has himself muted. A recording system is recording > > > everything Bob hears (including the whisper) and another > > recording system > > > monitor system records the stuff Carla hears and says. > > Carla's supervisor, > > > Zoe, joins the call and tries to form a sidebar with Carla > > and Bob but > > > Doug would still need to hear this sidebar since he hears > > everything Bob > > > hears. > > > > > > There are an infinite number of ways of forming a media > > graph that does > > > this conference. > > > > > > I have a hard time figuring out how Zoe's client is going to get the > > > current media graph and figure out what change it needs to > > make to this > > > media graph to form the sidebar and not violate the other > > constraints > > > about the what the recording systems need to record. I > > don't even know > > > how Zoe's client is going to present a user interface for > > what it can > > > change about this conference. > > > > > > Let's say that it did figure this all out and sent back a > > new media graph. > > > This new media graph needs to be run on a DSP platform that > > has several > > > DSPs. There are constraints to what can be cascaded. There > > are constraints > > > on how much can be run on a single DSP. There are other conferences > > > running on the same DSPs at the same time. There is highly > > optimized code > > > for some common situations. > > > > > > I don't know how the media graph is going to be compiled > > into a highly > > > optimized version of the conference that takes optimal use > > of the DSP and > > > does not violate any of the constraints. I worked on a > > compiler for a data > > > flow language that ran on a VLIW processor in a past life. > > The state of > > > the art in data flow optimizations is not all that great. > > > > > > It's not that any of this is impossible, it's just that it > > seems very hard > > > to implement. Perhaps I am just being dense and not seeing > > how all of this > > > would be done. I think I need some convincing that either > > 1) it actually > > > fairly easy to do or 2) it's only hard in really weird > > cases and we don't > > > care about those. I would like to hear from other people that might > > > actually implement such a system on how hard it would be > > and what tweaks > > > could be made that make it simpler. > > > > > > I was initially fairly keen on media graphs as a way of describing > > > conferences but the more I think about implementing them, the less > > > convinced I am that they are practical. > > > > > > Cullen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > Phone: +49 (0) 6221 905 11 29 > > Mobile: +49 (0) 163 275 17 43 > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Mon Nov 10 12:40:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02646 for ; Mon, 10 Nov 2003 12:40:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJG1H-0004s9-PL for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 12:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAHe7Z2018720 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 12:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJG1H-0004rN-8F for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02595 for ; Mon, 10 Nov 2003 12:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJG1E-00015U-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 12:40:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJG1E-00015R-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 12:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJG1E-0004r7-Cq; Mon, 10 Nov 2003 12:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJG17-0004qQ-Bv for xcon@optimus.ietf.org; Mon, 10 Nov 2003 12:39:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02589 for ; Mon, 10 Nov 2003 12:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJG15-00015I-00 for xcon@ietf.org; Mon, 10 Nov 2003 12:39:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AJG15-00014f-00 for xcon@ietf.org; Mon, 10 Nov 2003 12:39:55 -0500 Received: from nismail-w2k02.cisco.com (sjc-vpn4-80.cisco.com [10.21.80.80]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAAHdLrY018477; Mon, 10 Nov 2003 09:39:22 -0800 (PST) Message-Id: <4.3.2.7.2.20031110092600.00b69620@VTG-UM-E2K1> X-Sender: nismail@VTG-UM-E2K1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 09:39:21 -0800 To: "Rosen, Brian" From: Nermeen Ismail Subject: RE: [XCON] Concerns about mahy-xcon-media-policy-control Cc: "'Rohan Mahy'" , XCON-IETF In-Reply-To: <313680C9A886D511A06000204840E1CF070B60A7@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , It is an operation that takes an input group of streams and a parameter that identify the floor. The output of the operation is a stream. The operation semantics is that if one of the streams in the input group belongs to the current floor holder then the operation output stream is that stream. A usage scenario is that a user wants to see the current floor holder. The user client instantiates a floor holder operation, connects to its input the all participants video stream group and connects his output stream to the output of the operation. nermeen >It is not at all clear to me how you get a 'logical >holder of the floor foo' out of the draft. >What is that? A stream, a bundle, a component,...? > >Brian > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Monday, November 10, 2003 10:57 AM > > To: Eric Burger > > Cc: XCON-IETF > > Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control > > > > > > Hi, > > > > I'm sorry that I have not had time to issue a complete response to > > Cullen's post. However, in response to Eric's comment, I'd just like > > to understate the main difference between an approach like > > H.248 and an > > approach like the one in draft-mahy-xcon-media-policy... > > > > In H.248 if you want to mix in a person who has the floor you have to > > modify the connection parameters every time a different > > person gets the > > floor (first Alice, then Bob, the Zach...). In the media policy > > approach you ask that the logical holder(s) of floor foo are mixed in > > and the mixer takes care of the rest. > > > > We really have a meta issue to settle in XCON about what level of > > abstraction meets our requirements without being hideously complex. I > > will try to explain our choices in a balanced way on this > > issue when I > > present media policy open issues to XCON on Wednesday. If you'd like > > to contribute a slide or other material for this discussion, please > > send me a short mail or find me in Minneapolis. > > > > thanks, > > -rohan > > > > > > On Saturday, November 8, 2003, at 01:05 PM, Eric Burger wrote: > > > > > Chiming in, I would offer that for the "easy cases", it would be > > > better to say what we mean. E.g., rather than arbitrary > > graphs at the > > > RTP/DSP level, just say, "I want a sidebar" or "record this"? > > > > > > I really don't like the idea of replicating H.284.1 in XML :-) > > > > > >> -----Original Message----- > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > >> Sent: Tue, November 04, 2003 4:46 AM > > >> To: Cullen Jennings > > >> Cc: XCON-IETF > > >> Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control > > >> > > >> > > >> Cullen, > > >> > > >> I agree, your example scarce me as well. I don't think media > > >> graphs are > > >> helpful in most of the cases. Naturally, there are some very > > >> specific case > > >> where it might make sense. > > >> > > >> Marcus > > >> > > >> --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings > > >> wrote: > > >> > > >>> > > >>> I'm concerned that it will be incredibly difficult to build > > >> clients that > > >>> read the current media flow graph and can decided what > > >> needs to be changed > > >>> to perform some operation. I'm also concerted it will be > > >> very difficult to > > >>> build media processors that receive some graph and > > >> understand what they > > >>> need to actual do on the DSPs in a way that is efficient > > on the DSP > > >>> resources. > > >>> > > >>> Let me give an example. Alice has phoned a call center and is in a > > >>> conference that includes a call center agent Bob. Bob has > > >> conference in a > > >>> third party, called Carla, that validates that Alice said > > >> something was ok > > >>> to Bob. Bob supervisor, Doug, is listening to the call and > > >> can whisper to > > >>> Bob but currently has himself muted. A recording system > > is recording > > >>> everything Bob hears (including the whisper) and another > > >> recording system > > >>> monitor system records the stuff Carla hears and says. > > >> Carla's supervisor, > > >>> Zoe, joins the call and tries to form a sidebar with Carla > > >> and Bob but > > >>> Doug would still need to hear this sidebar since he hears > > >> everything Bob > > >>> hears. > > >>> > > >>> There are an infinite number of ways of forming a media > > >> graph that does > > >>> this conference. > > >>> > > >>> I have a hard time figuring out how Zoe's client is going > > to get the > > >>> current media graph and figure out what change it needs to > > >> make to this > > >>> media graph to form the sidebar and not violate the other > > >> constraints > > >>> about the what the recording systems need to record. I > > >> don't even know > > >>> how Zoe's client is going to present a user interface for > > >> what it can > > >>> change about this conference. > > >>> > > >>> Let's say that it did figure this all out and sent back a > > >> new media graph. > > >>> This new media graph needs to be run on a DSP platform that > > >> has several > > >>> DSPs. There are constraints to what can be cascaded. There > > >> are constraints > > >>> on how much can be run on a single DSP. There are other > > conferences > > >>> running on the same DSPs at the same time. There is highly > > >> optimized code > > >>> for some common situations. > > >>> > > >>> I don't know how the media graph is going to be compiled > > >> into a highly > > >>> optimized version of the conference that takes optimal use > > >> of the DSP and > > >>> does not violate any of the constraints. I worked on a > > >> compiler for a data > > >>> flow language that ran on a VLIW processor in a past life. > > >> The state of > > >>> the art in data flow optimizations is not all that great. > > >>> > > >>> It's not that any of this is impossible, it's just that it > > >> seems very hard > > >>> to implement. Perhaps I am just being dense and not seeing > > >> how all of this > > >>> would be done. I think I need some convincing that either > > >> 1) it actually > > >>> fairly easy to do or 2) it's only hard in really weird > > >> cases and we don't > > >>> care about those. I would like to hear from other people > > that might > > >>> actually implement such a system on how hard it would be > > >> and what tweaks > > >>> could be made that make it simpler. > > >>> > > >>> I was initially fairly keen on media graphs as a way of describing > > >>> conferences but the more I think about implementing them, the less > > >>> convinced I am that they are practical. > > >>> > > >>> Cullen > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> XCON mailing list > > >>> XCON@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/xcon > > >> > > >> > > >> > > >> -------------------------------------- > > >> Dr. Marcus Brunner > > >> Network Laboratories > > >> NEC Europe Ltd. > > >> > > >> E-Mail: brunner@ccrle.nec.de > > >> WWW: http://www.ccrle.nec.de/ > > >> Phone: +49 (0) 6221 905 11 29 > > >> Mobile: +49 (0) 163 275 17 43 > > >> personal home page: http://www.brubers.org/marcus > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 exim@www1.ietf.org Mon Nov 10 18:01:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19413 for ; Mon, 10 Nov 2003 18:01:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJL1s-0004Hp-Ua for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 18:01:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAN14mV016423 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 18:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJL1s-0004Ge-Jt for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 18:01:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19377 for ; Mon, 10 Nov 2003 18:00:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJL1p-0006nZ-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 18:01:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJL1p-0006nW-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 18:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJL1r-0004ET-9E; Mon, 10 Nov 2003 18:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJL1e-0004D9-Ai for xcon@optimus.ietf.org; Mon, 10 Nov 2003 18:00:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19370 for ; Mon, 10 Nov 2003 18:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJL1b-0006nN-00 for xcon@ietf.org; Mon, 10 Nov 2003 18:00:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJL1a-0006kk-00 for xcon@ietf.org; Mon, 10 Nov 2003 18:00:46 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 15:06:34 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAN0BB1008265; Mon, 10 Nov 2003 15:00:15 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK84664; Mon, 10 Nov 2003 15:00:11 -0800 (PST) Date: Mon, 10 Nov 2003 11:43:34 -0800 Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: XCON-IETF To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B60A7@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <2BDB8578-13B6-11D8-B472-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday, November 10, 2003, at 08:26 AM, Rosen, Brian wrote: > It is not at all clear to me how you get a 'logical > holder of the floor foo' out of the draft. > What is that? A stream, a bundle, a component,...? All the holders of the floor are represented by a set and a bundle which represents all the logical streams which correspond to that set. thx, -rohan > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Monday, November 10, 2003 10:57 AM >> To: Eric Burger >> Cc: XCON-IETF >> Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control >> >> >> Hi, >> >> I'm sorry that I have not had time to issue a complete response to >> Cullen's post. However, in response to Eric's comment, I'd just like >> to understate the main difference between an approach like >> H.248 and an >> approach like the one in draft-mahy-xcon-media-policy... >> >> In H.248 if you want to mix in a person who has the floor you have to >> modify the connection parameters every time a different >> person gets the >> floor (first Alice, then Bob, the Zach...). In the media policy >> approach you ask that the logical holder(s) of floor foo are mixed in >> and the mixer takes care of the rest. >> >> We really have a meta issue to settle in XCON about what level of >> abstraction meets our requirements without being hideously complex. I >> will try to explain our choices in a balanced way on this >> issue when I >> present media policy open issues to XCON on Wednesday. If you'd like >> to contribute a slide or other material for this discussion, please >> send me a short mail or find me in Minneapolis. >> >> thanks, >> -rohan >> >> >> On Saturday, November 8, 2003, at 01:05 PM, Eric Burger wrote: >> >>> Chiming in, I would offer that for the "easy cases", it would be >>> better to say what we mean. E.g., rather than arbitrary >> graphs at the >>> RTP/DSP level, just say, "I want a sidebar" or "record this"? >>> >>> I really don't like the idea of replicating H.284.1 in XML :-) >>> >>>> -----Original Message----- >>>> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >>>> Sent: Tue, November 04, 2003 4:46 AM >>>> To: Cullen Jennings >>>> Cc: XCON-IETF >>>> Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control >>>> >>>> >>>> Cullen, >>>> >>>> I agree, your example scarce me as well. I don't think media >>>> graphs are >>>> helpful in most of the cases. Naturally, there are some very >>>> specific case >>>> where it might make sense. >>>> >>>> Marcus >>>> >>>> --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings >>>> wrote: >>>> >>>>> >>>>> I'm concerned that it will be incredibly difficult to build >>>> clients that >>>>> read the current media flow graph and can decided what >>>> needs to be changed >>>>> to perform some operation. I'm also concerted it will be >>>> very difficult to >>>>> build media processors that receive some graph and >>>> understand what they >>>>> need to actual do on the DSPs in a way that is efficient >> on the DSP >>>>> resources. >>>>> >>>>> Let me give an example. Alice has phoned a call center and is in a >>>>> conference that includes a call center agent Bob. Bob has >>>> conference in a >>>>> third party, called Carla, that validates that Alice said >>>> something was ok >>>>> to Bob. Bob supervisor, Doug, is listening to the call and >>>> can whisper to >>>>> Bob but currently has himself muted. A recording system >> is recording >>>>> everything Bob hears (including the whisper) and another >>>> recording system >>>>> monitor system records the stuff Carla hears and says. >>>> Carla's supervisor, >>>>> Zoe, joins the call and tries to form a sidebar with Carla >>>> and Bob but >>>>> Doug would still need to hear this sidebar since he hears >>>> everything Bob >>>>> hears. >>>>> >>>>> There are an infinite number of ways of forming a media >>>> graph that does >>>>> this conference. >>>>> >>>>> I have a hard time figuring out how Zoe's client is going >> to get the >>>>> current media graph and figure out what change it needs to >>>> make to this >>>>> media graph to form the sidebar and not violate the other >>>> constraints >>>>> about the what the recording systems need to record. I >>>> don't even know >>>>> how Zoe's client is going to present a user interface for >>>> what it can >>>>> change about this conference. >>>>> >>>>> Let's say that it did figure this all out and sent back a >>>> new media graph. >>>>> This new media graph needs to be run on a DSP platform that >>>> has several >>>>> DSPs. There are constraints to what can be cascaded. There >>>> are constraints >>>>> on how much can be run on a single DSP. There are other >> conferences >>>>> running on the same DSPs at the same time. There is highly >>>> optimized code >>>>> for some common situations. >>>>> >>>>> I don't know how the media graph is going to be compiled >>>> into a highly >>>>> optimized version of the conference that takes optimal use >>>> of the DSP and >>>>> does not violate any of the constraints. I worked on a >>>> compiler for a data >>>>> flow language that ran on a VLIW processor in a past life. >>>> The state of >>>>> the art in data flow optimizations is not all that great. >>>>> >>>>> It's not that any of this is impossible, it's just that it >>>> seems very hard >>>>> to implement. Perhaps I am just being dense and not seeing >>>> how all of this >>>>> would be done. I think I need some convincing that either >>>> 1) it actually >>>>> fairly easy to do or 2) it's only hard in really weird >>>> cases and we don't >>>>> care about those. I would like to hear from other people >> that might >>>>> actually implement such a system on how hard it would be >>>> and what tweaks >>>>> could be made that make it simpler. >>>>> >>>>> I was initially fairly keen on media graphs as a way of describing >>>>> conferences but the more I think about implementing them, the less >>>>> convinced I am that they are practical. >>>>> >>>>> Cullen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> XCON mailing list >>>>> XCON@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >>>> >>>> >>>> -------------------------------------- >>>> Dr. Marcus Brunner >>>> Network Laboratories >>>> NEC Europe Ltd. >>>> >>>> E-Mail: brunner@ccrle.nec.de >>>> WWW: http://www.ccrle.nec.de/ >>>> Phone: +49 (0) 6221 905 11 29 >>>> Mobile: +49 (0) 163 275 17 43 >>>> personal home page: http://www.brubers.org/marcus >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 exim@www1.ietf.org Mon Nov 10 18:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20847 for ; Mon, 10 Nov 2003 18:12:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLCX-00057W-L2 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 18:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANC5E8019676 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 18:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLCX-00057H-DD for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 18:12:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20755 for ; Mon, 10 Nov 2003 18:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLCT-0006zi-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 18:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJLCS-0006zc-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 18:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLCU-00056N-7V; Mon, 10 Nov 2003 18:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLCM-00055u-8N for xcon@optimus.ietf.org; Mon, 10 Nov 2003 18:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20697 for ; Mon, 10 Nov 2003 18:11:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLCJ-0006yZ-00 for xcon@ietf.org; Mon, 10 Nov 2003 18:11:51 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJLCI-0006yV-00 for xcon@ietf.org; Mon, 10 Nov 2003 18:11:50 -0500 Received: from eunahlabtop (dyn143-191.ietf58.ietf.org [130.129.143.191]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hAANBuKg006424; Mon, 10 Nov 2003 17:11:56 -0600 (CST) Message-ID: <011201c3a7e0$04bf61b0$bf8f8182@eunahlabtop> Reply-To: "Eunsook Kim" From: "Eunsook Kim" To: "Eric Burger" , References: <4A3384433CE2AB46A63468CB207E209D4F693E@zoe.office.snowshore.com> Subject: Re: [XCON] Comments on draft-ekim-xcon-cpcp-bb-00 Date: Tue, 11 Nov 2003 08:11:47 +0900 Organization: ETRI MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Content-Transfer-Encoding: base64 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RXJpYywgdGhhbmtzIGZvciB5b3VyIGludGVyZXN0cyBhbmQgY29tbWVudHMuIE15IGFuc3dlciBp cyBpbmxpbmUuDQoNCj5TZWN0aW9uIDM6DQo+V2h5IE1VU1QgdGhlIHByb3RvY29sIGJlIFhNTD8g IFRoZXJlIGlzIG5vdCByZWFzb24gZm9yIHRoaXMgaW1wbGVtZW50YXRpb24gY2hvaWNlIGJlaW5n IGEgcmVxdWlyZW1lbnQuICBPZiBjb3Vyc2UsIGV2ZXJ5b25lIGtub3dzIEkgd291bGQgZ28gPmJh bGxpc3RpYyBpZiBpdCB3YXMgQVNOLjEsIGJ1dCB0aGF0IHdvdWxkIGJlIGFuIGltcGxlbWVudGF0 aW9uIGNob2ljZSwgbm90IGEgbmVlZC4NCj4NCg0KSU1ITywgWE1MIHNlZW1zIHRvIGVhc3kgdG8g ZXhwcmVzcyBhbmQgZGVsaXZlciB0aGUgQ1BDUCBvcGVyYXRpb25zIHdoaWNoIHJlcXVlc3QgZnJl cXVlbnQgY2hhbmdlIG9mIHRoZSBzcGVjaWZpZWQgY29uZmVyZW5jZSBwb2xpY3kgZG9jdWVtZW50 Lg0KKEl0IGlzIHNvbWV3aGF0IGltcGxlbWVudG9yJ3MgdmlldywgdGhvdWdoKQ0KSW4gZ2VuZXJh bCBiZWhhdmlvciBvZiBDUENQLCBjbGllbnRzIHJlcXVlc3QgdG8gY3JlYXRlL2RlbGV0ZSwgbGlz dCwgb3IgbW9kaWZ5IGEgc3BlY2lmaWMgY29uZmVyZW5jZSBpbmZvcm1hdGlvbi4gV2hlbiBjbGll bnRzIHJlcXVlc3QgdG8gbW9kaWZ5IGEgc3BlY2lmaWMgZWxlbWVudCAoc3VjaCBhcyBjb25mZXJl bmNlIHRpbWUgaW4gZ2VuZXJhbCBpbmZvcm1hdGlvbiwgdXNlciBpbmZvIGluIHBhcnRpY2lwYW50 cyBtYW5hZ2VtbnQgaW5mb3JtYXRpb24sIGV0Yy4pIGNsaWVudHMgZWFzaWx5IGRlc2NyaWJlIHRo ZSByZXF1ZXN0IGluZm9ybWF0aW9uIChpbiB3aGljaCBjb25mZXJlbmNlLCBvZiB3aGljaCBlbGVt ZW50KSB3aXRoIFhwYXRoIGFuZCBYcG9zaXRpb24gaWYgaXQgaXMgb3JpZ2luYWxseSB3cml0dGVu IGluIFhNTCwgd2l0aG91dCBkZWxpdmVyaW5nIHRoZSB3aG9sZSBkb2N1bWVudC4gIElmIENQUyBy ZWNlaXZlZCB0aGUgcmVxdWVzdCwgYW4gWE1MIHBhcnNlciBkZWNvZGUgdGhlIHJlcXVlc3QsIGFu ZCBDUFMgZ2V0cyB0aGUgZGVjb2RlZCByZXF1ZXN0ZWQgZWxlbWVudHMuIE1vcmVvdmVyLCBOT1RJ RlkgaW4gUkZDMzI2NSBhbmQgdGhlIGNvbmZlcmVuY2UgcGFja2FnZSBkb2N1bWVudCBhbHJlYWR5 IHVzZSBYTUwsIHNvIG1hbnkgb2YgQVBJcyBmb3IgaGFuZGxpbmcgdGhlIGluZm9ybWF0aW4gY2Fu IGJlIHJlLXVzZWQgKHNvbWV0aW1lcyB3aXRoIHNtYWxsIG1vZGlmaWNhdGlvbikuIA0KSWYgd2Ug dXNlIHRleHQsIGJvdGggY2xpZW50cyBhbmQgdGhlIENQUyBuZWVkIHRvIGltcGxlbWVudCBlbmNv ZGUgYW5kIGRlY29kZSBtb2R1bGVzLCB1bmxpa2VseSB0byB1c2Ugd2VsbC1rbm93biBwYXJzZXIg aW4gWE1MIGNhc2UuIEl0IGlzIGFsc28gbmVlZGVkIHRvIGhvbGQgdmFyaW91cyB2YXJpYmxlcyB0 byBjb250YWluIHRoZSBtYW55IGtpbmRzIG9mIGNvbmZlcmVuY2UgaW5mb3JtYXRpb24uDQoNCkFi b3V0IHlvdSBvcGluaW9uIHRoYXQgaXQgd291bGQgYmUgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNl LCBJIHRoaW5rIGl0J3MgYmV0dGVyIHRvIGhhdmUgYSBzdGFuZGFyZCBtZWNoYW5pc20gbGlrZSBT RFAgcmF0aGVyIHRoYW4gd2UgbGVhdmUgaXQgYXMgaW1wbGVtZW50b3IncyBjaG9pY2Ugd2hlbiBJ IGNvbmNlcm4gaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIENQUyBhbmQgZGlmZmVyZW50IGNvbXBh bmllcydzIGNsaWVudHMuIA0KDQo+SSBkb24ndCB0aGluayB0aGUgZG9jdW1lbnQgbWVhbnMgdGhl IGZvY3VzIHdvdWxkIGFzayB0aGUgQ1BTIGZvciBhdXRoZW50aWNhdGlvbiBvZiBwYXJ0aWNpcGFu dHMuICBBdXRoZW50aWNhdGlvbiBtZWFucyBwcm92aW5nICp3aG8qIHRoZSBjbGllbnQgaXMuICA+ VGhlIENQUyB3b3VsZCBiZSBuZWVkZWQgdG8gZGVjaWRlIGlmIHRoZSBjbGllbnQgaXMgKmF1dGhv cml6ZWQqLiAgSXQgaXMgcHJvYmFibHkgdXNlZnVsIHRvIHNheSB0aGUgdHJhbnNwb3J0IHByb3Rv Y29sIChlLmcuLCBodHRwL1NPQVAsIFNJUCwgZXRjLikgPndvdWxkIHByb3ZpZGUgdGhlIGF1dGhl bnRpY2F0aW9uIGZ1bmN0aW9uLg0KPg0KDQpZZXMsIGF1dGhvcml6YXRpb24gd291bGQgYmUgdGhl IHByb3BlciBleHByZXNzaW9uLiBUaGFua3MuDQoNCj4NCj5TZWN0aW9uIDYuMToNCj5XaGF0IGlz IHRoZSB2YWx1ZSBvZiBzcGVjaWZ5aW5nIHN0YXRpYyB2ZXJzdXMgZHluYW1pYyBjbG9zZWQgY29u ZmVyZW5jZXM/ICBGb3IgZXhhbXBsZSwgYSBjbGllbnQgY2Fubm90IHRlbGwgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiBhIGNsb3NlZCA+Y29uZmVyZW5jZSBhbmQgYSBjb25mZXJlbmNlIHRoYXQgaGFz IGl0cyBtYXhpbXVtIG51bWJlciBvZiBwYXJ0aWNpcGFudHMuICBFaXRoZXIgd2F5LCBhIG5ldyBw YXJ0aWNpcGFudCBjYW5ub3Qgam9pbi4gIEhvdyBhYm91dCBtYWtpbmcgYXZhaWxhYmlsaXR5ID50 byBqb2luIGEgc2VwYXJhdGUgcGFyYW1ldGVyIChpZiB0aGF0IGlzIHVzZWZ1bCk/DQo+DQoNCldl bGwsIHlvdSBhcmUgcmlnaHQuIHRvIGRlZmluZSBzdGF0aWMgb3IgZHluYW1pYyBjbG9zZWQgY29u ZmVyZW5jZSBoYXMgaXRzIHZhbHVlIG9ubHkgYmVmb3JlIGl0IHJlYWNoZXMgdGhlIG1heGltdW0g bnVtYmVyIG9mIHBhcnRpY2lwYW50cy4gDQpUbyBjb25zaWRlciB0aGlzIHBlcnNwZWN0aXZlLCB3 ZSBtYXkgZGVmaW5lICdhdmFpbGFibGlsaXR5IHRvIGpvaW4nLCBhcyB5b3VyIHN1Z2dlc3Rpb24u DQoNCj5TZWN0aW9uIDYuMToNCj5Eb2VzIHRoZSBjb25mZXJlbmNlIHRpbWUgZWxlbWVudCBzYXkg d2hlbiB0aGUgY29uZmVyZW5jZSBXSUxMIEJFLCBvciB3aGVuIHRoZSBjb25mZXJlbmNlIFdBUy4g IFRoZSB0ZXh0IGltcGxpZXMgZnV0dXJlIHNjaGVkdWxpbmcuICBUaGF0IGNvdWxkID5iZSBjbGVh cmVyLg0KDQpva2F5LiBUaGFua3MgZm9yIHRoZSBjb21tZW50Lg0KDQo+DQo+U2VjdGlvbiA3LjEu MjoNCj5XaHkgaXMgY29uZi1uYW1lIHByZXNlbnQ/ICBJZiBjb25mLVVSSSBpcyBwcmVzZW50ICht YW5kYXRvcnksIHNvIGl0IHNob3VsZCBiZSksIHRoYXQgaXMgZW5vdWdoIHRvIHVuaXF1ZWx5IGlk ZW50aWZ5IHRoZSBjb25mZXJlbmNlLiAgQWRkaW5nIGNvbmYtPm5hbWUgY29uZnVzZXMgdGhpbmdz LiAgRm9yIGV4YW1wbGUsIHdoYXQgaWYgY29uZi1uYW1lIGRvZXMgbm90IG1hdGNoIGNvbmYtVVJJ PyAgVGhhdCBhZGRzIGFuIGVycm9yIGNvbmRpdGlvbiB0byBoYW5kbGUuDQoNCj5BbGxvd2luZyBj b25mLW5hbWUgd291bGQgbWFrZSBzZW5zZSBpZiB5b3UgY291bGQgaWRlbnRpZnkgdGhlIGNvbmZl cmVuY2UgdG8gYmUgZGVzdHJveWVkIGJ5ICplaXRoZXIqIGNvbmYtbmFtZSBvciBjb25mLVVSSS4g IEhvd2V2ZXIsIHRoYXQgPmFkZHMgYW5vdGhlciBuZXcgZXJyb3IgY29uZGl0aW9uLiAgSSBkb24n dCB0aGluayBjb25mLW5hbWUgaXMgbmVjZXNzYXJpbHkgdW5pcXVlLiAgVGh1cyBvbmUgd291bGQg aGF2ZSB0byBoYW5kbGUgdGhlICJhbWJpZ3VvdXMgbmFtZSIgZXJyb3IgPmNvbmRpdGlvbi4NCj4N Cj5BbGxvd2luZyBvbmx5IGNvbmYtVVJJIGlzIHNvIG11Y2ggY2xlYW5lci4NCj4NCg0KSSB0aG91 Z2h0IHRoYXQgJ2NvbmYtVVJJJyBpcyB0aGUgb25seSBtZW5kYXRvcnkgZWxlbWVudCwgYW5kICdj b25mLW5hbWUnIGlzIG9ubHkgZm9yIGV4dHJhIGluZm9ybWF0aW9uLg0KQWN0dWFsbHksIEkgZGlk bid0IGNoZWNrICdjb25mLW5hbWUnIHdoZW4gSSBpbXBsZW1lbnRlZC4gWWVzLCBpZiBpdCBpcyBh IGNvbmZ1c2VzIHRoaW5ncywgaXQgd291bGQgYmUgYmV0dGVyIHRvIHJlbW92ZWQuIA0KVGhhbmtz IGZvciB0aGUgY29tbWVudC4NCg0KDQpFdW5zb29rIEtpbSANCg== _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Nov 10 18:21:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21734 for ; Mon, 10 Nov 2003 18:21:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLLE-0005Qi-CU for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 18:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANL4UF020871 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 18:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLLE-0005QW-5U for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 18:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21724 for ; Mon, 10 Nov 2003 18:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLLB-0007BJ-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 18:21:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJLLA-0007BG-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 18:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLLD-0005Po-43; Mon, 10 Nov 2003 18:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLKj-0005Nx-NI for xcon@optimus.ietf.org; Mon, 10 Nov 2003 18:20:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21709 for ; Mon, 10 Nov 2003 18:20:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLKg-0007Ap-00 for xcon@ietf.org; Mon, 10 Nov 2003 18:20:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJLKg-000798-00 for xcon@ietf.org; Mon, 10 Nov 2003 18:20:30 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 15:23:19 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAANJww5006904; Mon, 10 Nov 2003 15:19:58 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK87043; Mon, 10 Nov 2003 15:19:56 -0800 (PST) Date: Mon, 10 Nov 2003 17:19:56 -0600 Subject: Re: [XCON] Comments on draft-ekim-xcon-cpcp-bb-00 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Eric Burger" , To: "Eunsook Kim" From: Rohan Mahy In-Reply-To: <011201c3a7e0$04bf61b0$bf8f8182@eunahlabtop> Message-Id: <656CD2E9-13D4-11D8-A3F9-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsook, To summarize. It is a requirement that we pick something. It is not a requirement that we pick XML. We are very likely to pick XML anyway, but not because it is a requirement. thanks, -rohan On Monday, November 10, 2003, at 05:11 PM, Eunsook Kim wrote: > Eric, thanks for your interests and comments. My answer is inline. > >> Section 3: >> Why MUST the protocol be XML? There is not reason for this >> implementation choice being a requirement. Of course, everyone knows >> I would go >ballistic if it was ASN.1, but that would be an >> implementation choice, not a need. >> > > IMHO, XML seems to easy to express and deliver the CPCP operations > which request frequent change of the specified conference policy > docuement. > (It is somewhat implementor's view, though) > In general behavior of CPCP, clients request to create/delete, list, > or modify a specific conference information. When clients request to > modify a specific element (such as conference time in general > information, user info in participants managemnt information, etc.) > clients easily describe the request information (in which conference, > of which element) with Xpath and Xposition if it is originally written > in XML, without delivering the whole document. If CPS received the > request, an XML parser decode the request, and CPS gets the decoded > requested elements. Moreover, NOTIFY in RFC3265 and the conference > package document already use XML, so many of APIs for handling the > informatin can be re-used (sometimes with small modification). > If we use text, both clients and the CPS need to implement encode and > decode modules, unlikely to use well-known parser in XML case. It is > also needed to hold various varibles to contain the many kinds of > conference information. > > About you opinion that it would be an implementation choice, I think > it's better to have a standard mechanism like SDP rather than we leave > it as implementor's choice when I concern interoperability between CPS > and different companies's clients. > >> I don't think the document means the focus would ask the CPS for >> authentication of participants. Authentication means proving *who* >> the client is. >The CPS would be needed to decide if the client is >> *authorized*. It is probably useful to say the transport protocol >> (e.g., http/SOAP, SIP, etc.) >would provide the authentication >> function. >> > > Yes, authorization would be the proper expression. Thanks. > >> >> Section 6.1: >> What is the value of specifying static versus dynamic closed >> conferences? For example, a client cannot tell the difference >> between a closed >conference and a conference that has its maximum >> number of participants. Either way, a new participant cannot join. >> How about making availability >to join a separate parameter (if that >> is useful)? >> > > Well, you are right. to define static or dynamic closed conference has > its value only before it reaches the maximum number of participants. > To consider this perspective, we may define 'availablility to join', > as your suggestion. > >> Section 6.1: >> Does the conference time element say when the conference WILL BE, or >> when the conference WAS. The text implies future scheduling. That >> could >be clearer. > > okay. Thanks for the comment. > >> >> Section 7.1.2: >> Why is conf-name present? If conf-URI is present (mandatory, so it >> should be), that is enough to uniquely identify the conference. >> Adding conf->name confuses things. For example, what if conf-name >> does not match conf-URI? That adds an error condition to handle. > >> Allowing conf-name would make sense if you could identify the >> conference to be destroyed by *either* conf-name or conf-URI. >> However, that >adds another new error condition. I don't think >> conf-name is necessarily unique. Thus one would have to handle the >> "ambiguous name" error >condition. >> >> Allowing only conf-URI is so much cleaner. >> > > I thought that 'conf-URI' is the only mendatory element, and > 'conf-name' is only for extra information. > Actually, I didn't check 'conf-name' when I implemented. Yes, if it is > a confuses things, it would be better to removed. > Thanks for the comment. > > > Eunsook Kim > _______________________________________________ > 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 exim@www1.ietf.org Mon Nov 10 21:37:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00828 for ; Mon, 10 Nov 2003 21:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOOu-000856-17 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 21:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2b3CM031054 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 21:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOOt-000835-55 for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:37:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00775 for ; Mon, 10 Nov 2003 21:36:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOOo-00031R-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 21:36:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJOOo-00031O-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 21:36:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOOq-00082Q-Gj; Mon, 10 Nov 2003 21:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOOB-00081E-LN for xcon@optimus.ietf.org; Mon, 10 Nov 2003 21:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00730 for ; Mon, 10 Nov 2003 21:36:05 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOO8-00030a-00 for xcon@ietf.org; Mon, 10 Nov 2003 21:36:16 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJOO7-00030Q-00 for xcon@ietf.org; Mon, 10 Nov 2003 21:36:15 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB2aFc22084 for ; Tue, 11 Nov 2003 04:36:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 04:36:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 04:36:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Nov 2003 04:36:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 Date: Tue, 11 Nov 2003 04:36:12 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AC@esebe019.ntc.nokia.com> Thread-Topic: Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 Thread-Index: AcOlbR7Jiv7ln8HwTD2IDZMiQYYIwgCjr5tA To: , X-OriginalArrivalTime: 11 Nov 2003 02:36:13.0546 (UTC) FILETIME=[92F25CA0:01C3A7FC] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It is the former. They are split into 2 requirements because we felt = that they are not tied together, solution wise and do not need to be = solved together. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: Friday, November 07, 2003 11:20 PM > To: xcon@ietf.org > Subject: [XCON] Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 >=20 >=20 > The document doubles many of the requirements by saying: >=20 > REQ-n It MUST be possible to do X. >=20 > REQ-(n+1) It MUST be possible to do X to many Y in a=20 > single operation. >=20 >=20 > First question: by single operation, is the goal to reduce=20 > the number of messages (e.g., mass ejecting 100 people using=20 > 1 message instead of 100)? Or, is the goal to have atomic=20 > transactions (e.g., if I can't change all of the privileges=20 > for all of the users in the update request, fail the entire request). >=20 > If it is the former, why not just state one requirement to be=20 > able to batch requests? That cuts down on the number of=20 > requirements by almost half. >=20 > If it is the latter, why not just state one requirement to=20 > have atomic multiple operation transactions? >=20 > The benefit is you can then do both, if that is what the=20 > client really needs. >=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 From exim@www1.ietf.org Mon Nov 10 22:19:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02142 for ; Mon, 10 Nov 2003 22:19:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJP3W-0002eI-Ex for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 22:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3J25r010179 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 22:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJP3W-0002e6-84 for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:19:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02138 for ; Mon, 10 Nov 2003 22:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJP3T-0003ac-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 22:18:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJP3S-0003aZ-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 22:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJP3U-0002do-UT; Mon, 10 Nov 2003 22:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJP3M-0002dW-D0 for xcon@optimus.ietf.org; Mon, 10 Nov 2003 22:18:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02135 for ; Mon, 10 Nov 2003 22:18:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJP3J-0003aW-00 for xcon@ietf.org; Mon, 10 Nov 2003 22:18:49 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AJP3I-0003aD-00 for xcon@ietf.org; Mon, 10 Nov 2003 22:18:48 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 949; Mon, 10 Nov 2003 22:25:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 Date: Mon, 10 Nov 2003 22:18:19 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6994@zoe.office.snowshore.com> Thread-Topic: Aggregate requests in on koskelainen-xcon-cpcp-reqs-01 Thread-Index: AcOlbR7Jiv7ln8HwTD2IDZMiQYYIwgCjr5tAAAE3ILA= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Looking at the requirements, I can't figure out why a particular = requirement would have different implementation requirements than = another. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Mon, November 10, 2003 9:36 PM > To: Eric Burger; xcon@ietf.org > Subject: RE: [XCON] Aggregate requests in on > koskelainen-xcon-cpcp-reqs-01 >=20 >=20 > It is the former. They are split into 2 requirements because=20 > we felt that they are not tied together, solution wise and do=20 > not need to be solved together. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: Friday, November 07, 2003 11:20 PM > > To: xcon@ietf.org > > Subject: [XCON] Aggregate requests in on=20 > koskelainen-xcon-cpcp-reqs-01 > >=20 > >=20 > > The document doubles many of the requirements by saying: > >=20 > > REQ-n It MUST be possible to do X. > >=20 > > REQ-(n+1) It MUST be possible to do X to many Y in a=20 > > single operation. > >=20 > >=20 > > First question: by single operation, is the goal to reduce=20 > > the number of messages (e.g., mass ejecting 100 people using=20 > > 1 message instead of 100)? Or, is the goal to have atomic=20 > > transactions (e.g., if I can't change all of the privileges=20 > > for all of the users in the update request, fail the entire=20 > request). > >=20 > > If it is the former, why not just state one requirement to be=20 > > able to batch requests? That cuts down on the number of=20 > > requirements by almost half. > >=20 > > If it is the latter, why not just state one requirement to=20 > > have atomic multiple operation transactions? > >=20 > > The benefit is you can then do both, if that is what the=20 > > client really needs. > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Nov 10 23:50:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05511 for ; Mon, 10 Nov 2003 23:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQTb-0000Hu-M8 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 23:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB4o3bV001106 for xcon-archive@odin.ietf.org; Mon, 10 Nov 2003 23:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQTb-0000Hl-Ha for xcon-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 23:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05457 for ; Mon, 10 Nov 2003 23:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJQTZ-0004le-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 23:50:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJQTY-0004lW-00 for xcon-web-archive@ietf.org; Mon, 10 Nov 2003 23:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQTZ-0000FF-BN; Mon, 10 Nov 2003 23:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQSc-0008UQ-2l for xcon@optimus.ietf.org; Mon, 10 Nov 2003 23:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05401 for ; Mon, 10 Nov 2003 23:48:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJQSZ-0004jm-00 for xcon@ietf.org; Mon, 10 Nov 2003 23:48:59 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AJQSZ-0004jU-00 for xcon@ietf.org; Mon, 10 Nov 2003 23:48:59 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAB4nPA20160 for ; Mon, 10 Nov 2003 22:49:26 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XAS05>; Tue, 11 Nov 2003 04:48:25 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00A4FF9DB@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: xcon@ietf.org Date: Tue, 11 Nov 2003 04:48:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Comment on floor control requirements Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , In draft-koskelainen-xcon-floor-control-req-00 there are hints that some sort of queue exists when the number of participants requesting the floor exceeds the number of participants allows simultaneous use of the floor. For example REQ-10 refers to the number of simultaneous floor holders, and REQ-11 refers to passing the floor to the next in line after a time interval. It would appear to me that this queuing needs to be more extensively discussed in the above requirements document. Firstly REQ-11 implies that the queue is first in, first out (and I stress that this is an implication), whereas in real life certain users may preempt others in the queue. Secondly it would appear to be appropriate to have requirements for the floor control chair to have requirements for manipulating the queue, e.g. to designate the order of obtaining the floor, to clear the queue and so on. Additionally, perhaps other participants may also require visibility of the queue. My proposal would therefore to update the draft to explicitly define this queue concept, and then to revise the requirements to reflect the existence of the queue, and add requirements for the manipulation of the queue. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 11 11:17:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07801 for ; Tue, 11 Nov 2003 11:17:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbCQ-0003Qa-Ha for xcon-archive@odin.ietf.org; Tue, 11 Nov 2003 11:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGH238013170 for xcon-archive@odin.ietf.org; Tue, 11 Nov 2003 11:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbCQ-0003QL-Cw for xcon-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07767 for ; Tue, 11 Nov 2003 11:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbCP-0005Jj-00 for xcon-web-archive@ietf.org; Tue, 11 Nov 2003 11:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbCP-0005Jf-00 for xcon-web-archive@ietf.org; Tue, 11 Nov 2003 11:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbCP-0003Q3-0x; Tue, 11 Nov 2003 11:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbBl-0003PR-3T for xcon@optimus.ietf.org; Tue, 11 Nov 2003 11:16:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07744 for ; Tue, 11 Nov 2003 11:16:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbBk-0005JI-00 for xcon@ietf.org; Tue, 11 Nov 2003 11:16:20 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJbBj-0005JA-00 for xcon@ietf.org; Tue, 11 Nov 2003 11:16:19 -0500 Received: from dyn134-139.ietf58.ietf.org (dyn134-139.ietf58.ietf.org [130.129.134.139]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 696541037F; Tue, 11 Nov 2003 17:20:39 +0100 (CET) Date: Tue, 11 Nov 2003 10:16:14 -0600 From: Marcus Brunner Reply-To: Marcus Brunner To: "Drage, Keith (Keith)" Cc: xcon@ietf.org Subject: Re: [XCON] Comment on floor control requirements Message-ID: <104110192.1068545773@dyn134-139.ietf58.ietf.org> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00A4FF9DB@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00A4FF9DB@en0033exch001u.uk.luce nt.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit keith, > It would appear to me that this queuing needs to be more extensively > discussed in the above requirements document. > I think there should not be any restrictions on what queuing is needed. The mechanisms to be standardized should be free of any of these assumtions. > Firstly REQ-11 implies that the queue is first in, first out (and I > stress that this is an implication), whereas in real life certain users > may preempt others in the queue. > > Secondly it would appear to be appropriate to have requirements for the > floor control chair to have requirements for manipulating the queue, e.g. > to designate the order of obtaining the floor, to clear the queue and so > on. > I assume this to be implementation specific. > Additionally, perhaps other participants may also require visibility of > the queue. > that is good point, In draft-brunner I called it state awareness (so participants should be able to get information about the current state of the floor control mechnisms including also the queue state. > My proposal would therefore to update the draft to explicitly define this > queue concept, and then to revise the requirements to reflect the > existence of the queue, and add requirements for the manipulation of the > queue. > I oppose, this is really implementation/application specific and should not influence the design of the mechnism. Marcus > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 11 18:40:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28896 for ; Tue, 11 Nov 2003 18:40:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJi79-000166-Gs for xcon-archive@odin.ietf.org; Tue, 11 Nov 2003 18:40:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABNe3aE004212 for xcon-archive@odin.ietf.org; Tue, 11 Nov 2003 18:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJi79-00015r-5Z for xcon-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 18:40:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28887 for ; Tue, 11 Nov 2003 18:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJi76-0004Y5-00 for xcon-web-archive@ietf.org; Tue, 11 Nov 2003 18:40:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJi75-0004Y2-00 for xcon-web-archive@ietf.org; Tue, 11 Nov 2003 18:39:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJi77-00015Z-Tr; Tue, 11 Nov 2003 18:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJi6M-00011A-GN for xcon@optimus.ietf.org; Tue, 11 Nov 2003 18:39:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28849 for ; Tue, 11 Nov 2003 18:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJi6J-0004Xo-00 for xcon@ietf.org; Tue, 11 Nov 2003 18:39:11 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AJi6I-0004X6-00 for xcon@ietf.org; Tue, 11 Nov 2003 18:39:10 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hABNdcA00623 for ; Tue, 11 Nov 2003 17:39:39 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XBP6N>; Tue, 11 Nov 2003 23:38:36 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00A4FFB51@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Marcus Brunner , "Drage, Keith (Keith)" Cc: xcon@ietf.org Subject: RE: [XCON] Comment on floor control requirements Date: Tue, 11 Nov 2003 23:38:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , So firstly you do admit that the queue exists (when the number of people requesting the floor exceeds the number allowed to hold the floor. So I believe we can define the queue so that we can say meaningful things about it. I also believe we can at least document the impact of existing requirements on the queue, e.g. if someone requests the floor, they are added to the queue until the floor chair grants the request - that after all is just documenting what already implicitly exists in the document. The question I guess we may well differ is as to what is implementation specific, and what is actually defined in future protocol specifications as a result of requirements made in the requirements draft. I guess partly that depends on where the queue is held in relation to the floor chair. If it is in the local entity to the floor chair, then any requirements on the manipulation of the queue by the floor chair could be implementation specific. Any action by participants to see or modify the queue would have to be defined. However, I am not convinced that we are yet at the stage where we can agree that the queue is in the local entity to the floor chair, and maybe we should have some discussion about that. My input to that would be that in the wireless world, we are interested in minimising the bits on the air interface, and if centralising the queue reduces the protocol load, then we would certainly want to consider it. There is already a requirement in the requirements draft to take account of this impact. Certainly if they are in separate entities, we need requirements that cover the eventual protocol that must exist between the floor chair and queue, and it would be useful to also identify what of those exist. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 November 2003 16:16 > To: Drage, Keith (Keith) > Cc: xcon@ietf.org > Subject: Re: [XCON] Comment on floor control requirements > > > keith, > > > > It would appear to me that this queuing needs to be more extensively > > discussed in the above requirements document. > > > > I think there should not be any restrictions on what queuing > is needed. The > mechanisms to be standardized should be free of any of these > assumtions. > > > Firstly REQ-11 implies that the queue is first in, first out (and I > > stress that this is an implication), whereas in real life > certain users > > may preempt others in the queue. > > > > Secondly it would appear to be appropriate to have > requirements for the > > floor control chair to have requirements for manipulating > the queue, e.g. > > to designate the order of obtaining the floor, to clear the > queue and so > > on. > > > > I assume this to be implementation specific. > > > Additionally, perhaps other participants may also require > visibility of > > the queue. > > > > that is good point, In draft-brunner I called it state awareness (so > participants should be able to get information about the > current state of > the floor control mechnisms including also the queue state. > > > My proposal would therefore to update the draft to > explicitly define this > > queue concept, and then to revise the requirements to reflect the > > existence of the queue, and add requirements for the > manipulation of the > > queue. > > > > I oppose, this is really implementation/application specific > and should not > influence the design of the mechnism. > > Marcus > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 11 18:56:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29346 for ; Tue, 11 Nov 2003 18:56:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJiMc-0001y4-Iu for xcon-archive@odin.ietf.org; Tue, 11 Nov 2003 18:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABNu2Zd007558 for xcon-archive@odin.ietf.org; Tue, 11 Nov 2003 18:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJiMc-0001xp-En for xcon-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 18:56:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29330 for ; Tue, 11 Nov 2003 18:55:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJiMZ-0004iN-00 for xcon-web-archive@ietf.org; Tue, 11 Nov 2003 18:55:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJiMY-0004iK-00 for xcon-web-archive@ietf.org; Tue, 11 Nov 2003 18:55:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJiMb-0001xZ-Hu; Tue, 11 Nov 2003 18:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJiLi-0001wZ-CV for xcon@optimus.ietf.org; Tue, 11 Nov 2003 18:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29321 for ; Tue, 11 Nov 2003 18:54:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJiLa-0004hp-00 for xcon@ietf.org; Tue, 11 Nov 2003 18:54:58 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJiLa-0004hm-00 for xcon@ietf.org; Tue, 11 Nov 2003 18:54:58 -0500 Received: from dyn134-139.ietf58.ietf.org (dyn134-139.ietf58.ietf.org [130.129.134.139]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 988311037F; Wed, 12 Nov 2003 00:59:19 +0100 (CET) Date: Tue, 11 Nov 2003 17:54:54 -0600 From: Marcus Brunner Reply-To: Marcus Brunner To: "Drage, Keith (Keith)" Cc: xcon@ietf.org Subject: RE: [XCON] Comment on floor control requirements Message-ID: <14293743.1068573293@dyn134-139.ietf58.ietf.org> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00A4FFB51@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00A4FFB51@en0033exch001u.uk.luce nt.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit keith, the queue might exist for some floor control policies (e.g. for what i called the ietf model). What are the things you want to say about the queue? Except to distribute for example the size and on what position a certain participant is sitting. Marcus --On Tuesday, November 11, 2003 11:38 PM +0000 "Drage, Keith (Keith)" wrote: > So firstly you do admit that the queue exists (when the number of people > requesting the floor exceeds the number allowed to hold the floor. So I > believe we can define the queue so that we can say meaningful things > about it. > > I also believe we can at least document the impact of existing > requirements on the queue, e.g. if someone requests the floor, they are > added to the queue until the floor chair grants the request - that after > all is just documenting what already implicitly exists in the document. > > The question I guess we may well differ is as to what is implementation > specific, and what is actually defined in future protocol specifications > as a result of requirements made in the requirements draft. I guess > partly that depends on where the queue is held in relation to the floor > chair. If it is in the local entity to the floor chair, then any > requirements on the manipulation of the queue by the floor chair could be > implementation specific. Any action by participants to see or modify the > queue would have to be defined. > > However, I am not convinced that we are yet at the stage where we can > agree that the queue is in the local entity to the floor chair, and maybe > we should have some discussion about that. My input to that would be that > in the wireless world, we are interested in minimising the bits on the > air interface, and if centralising the queue reduces the protocol load, > then we would certainly want to consider it. There is already a > requirement in the requirements draft to take account of this impact. > > Certainly if they are in separate entities, we need requirements that > cover the eventual protocol that must exist between the floor chair and > queue, and it would be useful to also identify what of those exist. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 11 November 2003 16:16 >> To: Drage, Keith (Keith) >> Cc: xcon@ietf.org >> Subject: Re: [XCON] Comment on floor control requirements >> >> >> keith, >> >> >> > It would appear to me that this queuing needs to be more extensively >> > discussed in the above requirements document. >> > >> >> I think there should not be any restrictions on what queuing >> is needed. The >> mechanisms to be standardized should be free of any of these >> assumtions. >> >> > Firstly REQ-11 implies that the queue is first in, first out (and I >> > stress that this is an implication), whereas in real life >> certain users >> > may preempt others in the queue. >> > >> > Secondly it would appear to be appropriate to have >> requirements for the >> > floor control chair to have requirements for manipulating >> the queue, e.g. >> > to designate the order of obtaining the floor, to clear the >> queue and so >> > on. >> > >> >> I assume this to be implementation specific. >> >> > Additionally, perhaps other participants may also require >> visibility of >> > the queue. >> > >> >> that is good point, In draft-brunner I called it state awareness (so >> participants should be able to get information about the >> current state of >> the floor control mechnisms including also the queue state. >> >> > My proposal would therefore to update the draft to >> explicitly define this >> > queue concept, and then to revise the requirements to reflect the >> > existence of the queue, and add requirements for the >> manipulation of the >> > queue. >> > >> >> I oppose, this is really implementation/application specific >> and should not >> influence the design of the mechnism. >> >> Marcus >> >> > regards >> > >> > Keith >> > >> > Keith Drage >> > Lucent Technologies >> > drage@lucent.com >> > tel: +44 1793 776249 >> > >> > _______________________________________________ >> > XCON mailing list >> > XCON@ietf.org >> > https://www1.ietf.org/mailman/listinfo/xcon >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> Phone: +49 (0) 6221 905 11 29 >> Mobile: +49 (0) 163 275 17 43 >> personal home page: http://www.brubers.org/marcus >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Nov 12 00:24:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08697 for ; Wed, 12 Nov 2003 00:24:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnU4-00080T-7J for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 00:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC5O4Xo030764 for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 00:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnU3-0007zO-9D for xcon-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 00:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08537 for ; Wed, 12 Nov 2003 00:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnU0-0000zV-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 00:24:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJnU0-0000zQ-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 00:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnU1-0007w1-Dk; Wed, 12 Nov 2003 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJmPh-00048q-02 for xcon@optimus.ietf.org; Tue, 11 Nov 2003 23:15:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07070 for ; Tue, 11 Nov 2003 23:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJmPe-0000J9-00 for xcon@ietf.org; Tue, 11 Nov 2003 23:15:26 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJmPe-0000J6-00 for xcon@ietf.org; Tue, 11 Nov 2003 23:15:26 -0500 Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAC4FE9E008145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Nov 2003 23:15:14 -0500 (EST) Received: from disco.cs.columbia.edu (localhost [127.0.0.1]) by disco.cs.columbia.edu (8.12.10/8.12.6) with ESMTP id hAC4FDlp018732; Tue, 11 Nov 2003 23:15:13 -0500 (EST) Received: from localhost (xiaotaow@localhost) by disco.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id hAC4F54Q018729; Tue, 11 Nov 2003 23:15:13 -0500 (EST) X-Authentication-Warning: disco.cs.columbia.edu: xiaotaow owned process doing -bs Date: Tue, 11 Nov 2003 23:15:05 -0500 (EST) From: Xiaotao Wu To: Marcus Brunner cc: "Drage, Keith (Keith)" , Subject: RE: [XCON] Comment on floor control requirements In-Reply-To: <14293743.1068573293@dyn134-139.ietf58.ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , I think we should not explicitly mention 'queue' in the requirement document. 'queue' is just one way of implementing the collection for floor requests. How to define the queue and how to operate the queue is implementation issues. It should not be explicitly mentioned in the protocol. In our outdated draft draft-wu-sipping-floor-control-04.txt, we defined several queue operations for floor requests. Now I felt that to have the queue operations defined in a floor control protocol makes the protocol too complicated. I think a better way to represent the order of the requests is to use priority value for the requests. The priority value is just optional. In fact, for many common usages, we don't need to use the priority value to sort the requests. (1) for FIFO, time-stamp can be used to sort (2) for random, (like in a big conference, it does not make sense to pick a questioner based on who raise the hand first), no order at all (3) for chair-controlled, unless the other participants also want to see the order, the chair can keep the collection of requests locally on chair's UA, and there is no need to have queue operations between the chair and the conference server. If we do want to have the sorted collection on conference server and allows the chair to freely change the order, the chair can change the priority value of a request and the order can be changed. The participants can be notified of the priority value change and re-order their list. I think queue should not be explicitly mentioned. Otherwise, we need also mention the operations of the queue and make the protocol complicated. Thanks! -Xiaotao =========================================================== Name : Xiaotao Wu Email : xiaotaow@cs.columbia.edu, xiaotaow@tsinghua.com Homepage : http://www.cs.columbia.edu/~xiaotaow Phone : (212)939-7054, Fax: (801)751-0217 Phone-PC : (212)939-7133 SIP : sip:xiaotaow@conductor.cs.columbia.edu Office : Room 506, Mudd building, West 120th =========================================================== On Tue, 11 Nov 2003, Marcus Brunner wrote: > keith, > > the queue might exist for some floor control policies (e.g. for what i > called the ietf model). What are the things you want to say about the > queue? Except to distribute for example the size and on what position a > certain participant is sitting. > > Marcus > > > > --On Tuesday, November 11, 2003 11:38 PM +0000 "Drage, Keith (Keith)" > wrote: > > > So firstly you do admit that the queue exists (when the number of people > > requesting the floor exceeds the number allowed to hold the floor. So I > > believe we can define the queue so that we can say meaningful things > > about it. > > > > I also believe we can at least document the impact of existing > > requirements on the queue, e.g. if someone requests the floor, they are > > added to the queue until the floor chair grants the request - that after > > all is just documenting what already implicitly exists in the document. > > > > The question I guess we may well differ is as to what is implementation > > specific, and what is actually defined in future protocol specifications > > as a result of requirements made in the requirements draft. I guess > > partly that depends on where the queue is held in relation to the floor > > chair. If it is in the local entity to the floor chair, then any > > requirements on the manipulation of the queue by the floor chair could be > > implementation specific. Any action by participants to see or modify the > > queue would have to be defined. > > > > However, I am not convinced that we are yet at the stage where we can > > agree that the queue is in the local entity to the floor chair, and maybe > > we should have some discussion about that. My input to that would be that > > in the wireless world, we are interested in minimising the bits on the > > air interface, and if centralising the queue reduces the protocol load, > > then we would certainly want to consider it. There is already a > > requirement in the requirements draft to take account of this impact. > > > > Certainly if they are in separate entities, we need requirements that > > cover the eventual protocol that must exist between the floor chair and > > queue, and it would be useful to also identify what of those exist. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: 11 November 2003 16:16 > >> To: Drage, Keith (Keith) > >> Cc: xcon@ietf.org > >> Subject: Re: [XCON] Comment on floor control requirements > >> > >> > >> keith, > >> > >> > >> > It would appear to me that this queuing needs to be more extensively > >> > discussed in the above requirements document. > >> > > >> > >> I think there should not be any restrictions on what queuing > >> is needed. The > >> mechanisms to be standardized should be free of any of these > >> assumtions. > >> > >> > Firstly REQ-11 implies that the queue is first in, first out (and I > >> > stress that this is an implication), whereas in real life > >> certain users > >> > may preempt others in the queue. > >> > > >> > Secondly it would appear to be appropriate to have > >> requirements for the > >> > floor control chair to have requirements for manipulating > >> the queue, e.g. > >> > to designate the order of obtaining the floor, to clear the > >> queue and so > >> > on. > >> > > >> > >> I assume this to be implementation specific. > >> > >> > Additionally, perhaps other participants may also require > >> visibility of > >> > the queue. > >> > > >> > >> that is good point, In draft-brunner I called it state awareness (so > >> participants should be able to get information about the > >> current state of > >> the floor control mechnisms including also the queue state. > >> > >> > My proposal would therefore to update the draft to > >> explicitly define this > >> > queue concept, and then to revise the requirements to reflect the > >> > existence of the queue, and add requirements for the > >> manipulation of the > >> > queue. > >> > > >> > >> I oppose, this is really implementation/application specific > >> and should not > >> influence the design of the mechnism. > >> > >> Marcus > >> > >> > regards > >> > > >> > Keith > >> > > >> > Keith Drage > >> > Lucent Technologies > >> > drage@lucent.com > >> > tel: +44 1793 776249 > >> > > >> > _______________________________________________ > >> > XCON mailing list > >> > XCON@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/xcon > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> Phone: +49 (0) 6221 905 11 29 > >> Mobile: +49 (0) 163 275 17 43 > >> personal home page: http://www.brubers.org/marcus > >> > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Nov 12 11:18:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24975 for ; Wed, 12 Nov 2003 11:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxgw-0003xL-SV for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 11:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGI22B015199 for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 11:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxgw-0003x4-KJ for xcon-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:18:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24960 for ; Wed, 12 Nov 2003 11:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxgv-0001R6-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 11:18:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxgv-0001R0-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 11:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxgu-0003wi-RY; Wed, 12 Nov 2003 11:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxg4-0003uP-7v for xcon@optimus.ietf.org; Wed, 12 Nov 2003 11:17:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24892 for ; Wed, 12 Nov 2003 11:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxg3-0001Q4-00 for xcon@ietf.org; Wed, 12 Nov 2003 11:17:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJxg1-0001PS-00 for xcon@ietf.org; Wed, 12 Nov 2003 11:17:06 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2003 08:16:37 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACGGUxg009655; Wed, 12 Nov 2003 11:16:31 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ATV28002; Wed, 12 Nov 2003 08:16:29 -0800 (PST) Message-Id: <4.3.2.7.2.20031112111300.00ba40c8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Nov 2003 11:16:29 -0500 To: Xiaotao Wu From: Michael Hammer Subject: RE: [XCON] Comment on floor control requirements Cc: Marcus Brunner , "Drage, Keith (Keith)" , In-Reply-To: References: <14293743.1068573293@dyn134-139.ietf58.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Could you take an equivalent view that the time of a request is simply one of several attributes used to make a selection of one requesting party to the conference over another? The time of arrival of a request for the floor could be recorded along with the other attributes of the requestor, and then it is a policy matter for the chair in deciding who gets the floor next. Mike At 11:15 PM 11/11/2003 -0500, Xiaotao Wu wrote: >I think we should not explicitly mention 'queue' in the requirement >document. > >'queue' is just one way of implementing the collection for floor >requests. How to define the queue and how to operate the queue is >implementation issues. It should not be explicitly mentioned in the >protocol. > >In our outdated draft draft-wu-sipping-floor-control-04.txt, we >defined several queue operations for floor requests. Now I felt that to >have the queue operations defined in a floor control protocol makes the >protocol too complicated. > >I think a better way to represent the order of the requests is to use >priority value for the requests. The priority value is just optional. >In fact, for many common usages, we don't need to use the priority value >to sort the requests. > >(1) for FIFO, time-stamp can be used to sort >(2) for random, (like in a big conference, it does not make sense to pick >a questioner based on who raise the hand first), no order at all >(3) for chair-controlled, unless the other participants also want to see >the order, the chair can keep the collection of requests locally on >chair's UA, and there is no need to have queue operations between the >chair and the conference server. > >If we do want to have the sorted collection on conference server and >allows the chair to freely change the order, the chair can change the >priority value of a request and the order can be changed. The participants >can be notified of the priority value change and re-order their list. > >I think queue should not be explicitly mentioned. Otherwise, we need >also mention the operations of the queue and make the protocol >complicated. > >Thanks! > >-Xiaotao > >=========================================================== >Name : Xiaotao Wu >Email : xiaotaow@cs.columbia.edu, xiaotaow@tsinghua.com >Homepage : http://www.cs.columbia.edu/~xiaotaow >Phone : (212)939-7054, Fax: (801)751-0217 >Phone-PC : (212)939-7133 >SIP : sip:xiaotaow@conductor.cs.columbia.edu >Office : Room 506, Mudd building, West 120th >=========================================================== > >On Tue, 11 Nov 2003, Marcus Brunner wrote: > > > keith, > > > > the queue might exist for some floor control policies (e.g. for what i > > called the ietf model). What are the things you want to say about the > > queue? Except to distribute for example the size and on what position a > > certain participant is sitting. > > > > Marcus > > > > > > > > --On Tuesday, November 11, 2003 11:38 PM +0000 "Drage, Keith (Keith)" > > wrote: > > > > > So firstly you do admit that the queue exists (when the number of people > > > requesting the floor exceeds the number allowed to hold the floor. So I > > > believe we can define the queue so that we can say meaningful things > > > about it. > > > > > > I also believe we can at least document the impact of existing > > > requirements on the queue, e.g. if someone requests the floor, they are > > > added to the queue until the floor chair grants the request - that after > > > all is just documenting what already implicitly exists in the document. > > > > > > The question I guess we may well differ is as to what is implementation > > > specific, and what is actually defined in future protocol specifications > > > as a result of requirements made in the requirements draft. I guess > > > partly that depends on where the queue is held in relation to the floor > > > chair. If it is in the local entity to the floor chair, then any > > > requirements on the manipulation of the queue by the floor chair could be > > > implementation specific. Any action by participants to see or modify the > > > queue would have to be defined. > > > > > > However, I am not convinced that we are yet at the stage where we can > > > agree that the queue is in the local entity to the floor chair, and maybe > > > we should have some discussion about that. My input to that would be that > > > in the wireless world, we are interested in minimising the bits on the > > > air interface, and if centralising the queue reduces the protocol load, > > > then we would certainly want to consider it. There is already a > > > requirement in the requirements draft to take account of this impact. > > > > > > Certainly if they are in separate entities, we need requirements that > > > cover the eventual protocol that must exist between the floor chair and > > > queue, and it would be useful to also identify what of those exist. > > > > > > regards > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > drage@lucent.com > > > tel: +44 1793 776249 > > > > > >> -----Original Message----- > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > >> Sent: 11 November 2003 16:16 > > >> To: Drage, Keith (Keith) > > >> Cc: xcon@ietf.org > > >> Subject: Re: [XCON] Comment on floor control requirements > > >> > > >> > > >> keith, > > >> > > >> > > >> > It would appear to me that this queuing needs to be more extensively > > >> > discussed in the above requirements document. > > >> > > > >> > > >> I think there should not be any restrictions on what queuing > > >> is needed. The > > >> mechanisms to be standardized should be free of any of these > > >> assumtions. > > >> > > >> > Firstly REQ-11 implies that the queue is first in, first out (and I > > >> > stress that this is an implication), whereas in real life > > >> certain users > > >> > may preempt others in the queue. > > >> > > > >> > Secondly it would appear to be appropriate to have > > >> requirements for the > > >> > floor control chair to have requirements for manipulating > > >> the queue, e.g. > > >> > to designate the order of obtaining the floor, to clear the > > >> queue and so > > >> > on. > > >> > > > >> > > >> I assume this to be implementation specific. > > >> > > >> > Additionally, perhaps other participants may also require > > >> visibility of > > >> > the queue. > > >> > > > >> > > >> that is good point, In draft-brunner I called it state awareness (so > > >> participants should be able to get information about the > > >> current state of > > >> the floor control mechnisms including also the queue state. > > >> > > >> > My proposal would therefore to update the draft to > > >> explicitly define this > > >> > queue concept, and then to revise the requirements to reflect the > > >> > existence of the queue, and add requirements for the > > >> manipulation of the > > >> > queue. > > >> > > > >> > > >> I oppose, this is really implementation/application specific > > >> and should not > > >> influence the design of the mechnism. > > >> > > >> Marcus > > >> > > >> > regards > > >> > > > >> > Keith > > >> > > > >> > Keith Drage > > >> > Lucent Technologies > > >> > drage@lucent.com > > >> > tel: +44 1793 776249 > > >> > > > >> > _______________________________________________ > > >> > XCON mailing list > > >> > XCON@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/xcon > > >> > > >> > > >> > > >> -------------------------------------- > > >> Dr. Marcus Brunner > > >> Network Laboratories > > >> NEC Europe Ltd. > > >> > > >> E-Mail: brunner@ccrle.nec.de > > >> WWW: http://www.ccrle.nec.de/ > > >> Phone: +49 (0) 6221 905 11 29 > > >> Mobile: +49 (0) 163 275 17 43 > > >> personal home page: http://www.brubers.org/marcus > > >> > > >> > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > Phone: +49 (0) 6221 905 11 29 > > Mobile: +49 (0) 163 275 17 43 > > personal home page: http://www.brubers.org/marcus > > > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Nov 12 11:31:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25704 for ; Wed, 12 Nov 2003 11:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxtZ-00059f-LN for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 11:31:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGV556019809 for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 11:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxtZ-00059O-Eg for xcon-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25648 for ; Wed, 12 Nov 2003 11:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxtY-0001fK-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 11:31:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxtX-0001fH-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 11:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxtX-000580-5E; Wed, 12 Nov 2003 11:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxt3-0004uL-IT for xcon@optimus.ietf.org; Wed, 12 Nov 2003 11:30:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25597 for ; Wed, 12 Nov 2003 11:30:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxt2-0001cA-00 for xcon@ietf.org; Wed, 12 Nov 2003 11:30:32 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJxt0-0001bV-00 for xcon@ietf.org; Wed, 12 Nov 2003 11:30:31 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hACGTtGd020997 for ; Wed, 12 Nov 2003 10:29:55 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 10:29:56 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865F6@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Wed, 12 Nov 2003 10:29:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Slides Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , All of the slides that the chairs have received so far have been posted to the website. http://www.softarmor.com/xcon/meets/ietf58/agenda.pl If you are presenting and your slides are not here, please send them to me as soon as possible. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Nov 12 11:45:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26674 for ; Wed, 12 Nov 2003 11:45:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy7h-0007LN-B6 for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 11:45:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGjf2S028223 for xcon-archive@odin.ietf.org; Wed, 12 Nov 2003 11:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy7h-0007L8-5Z for xcon-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:45:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26626 for ; Wed, 12 Nov 2003 11:45:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy7g-0001yz-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 11:45:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJy7f-0001yQ-00 for xcon-web-archive@ietf.org; Wed, 12 Nov 2003 11:45:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy73-0007Hv-8e; Wed, 12 Nov 2003 11:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy69-0007Df-Sz for xcon@optimus.ietf.org; Wed, 12 Nov 2003 11:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26557 for ; Wed, 12 Nov 2003 11:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy68-0001xf-00 for xcon@ietf.org; Wed, 12 Nov 2003 11:44:04 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJy67-0001xc-00 for xcon@ietf.org; Wed, 12 Nov 2003 11:44:03 -0500 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hACGf39E029898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Nov 2003 11:41:03 -0500 (EST) Received: from dynasty.cs.columbia.edu (localhost [127.0.0.1]) by dynasty.cs.columbia.edu (8.12.10/8.12.9) with ESMTP id hACGexg9024658; Wed, 12 Nov 2003 11:40:59 -0500 (EST) Received: from localhost (xiaotaow@localhost) by dynasty.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id hACGewYP024655; Wed, 12 Nov 2003 11:40:58 -0500 (EST) X-Authentication-Warning: dynasty.cs.columbia.edu: xiaotaow owned process doing -bs Date: Wed, 12 Nov 2003 11:40:58 -0500 (EST) From: Xiaotao Wu To: Michael Hammer cc: Marcus Brunner , "Drage, Keith (Keith)" , Subject: RE: [XCON] Comment on floor control requirements In-Reply-To: <4.3.2.7.2.20031112111300.00ba40c8@cia.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , On Wed, 12 Nov 2003, Michael Hammer wrote: > Could you take an equivalent view that the time of a request is simply one > of several attributes used to make a selection of one requesting party to > the conference over another? The time of arrival of a request for the > floor could be recorded along with the other attributes of the requestor, > and then it is a policy matter for the chair in deciding who gets the floor > next. Hi, Mike, Right, time is just one of the attributes, though it may be the most important attributes. As I stated in my last email, the order is not only based on 'time'. The chair can change the order, for example, change the priority of a floor request. The main point is, queue is just about how to implement the order. If we define queue in the protocol, where will the queue reside? If the queue resides in the conference server, should we define queue operations from the moderator to the conference server? If we want to define the queue operations, should we define a full-fledge queue operations for floor control? To explicity define queue in the protocol will make the protocol too complicated. Especially, it should not be in the requirement document. Thanks, -xiaotao > > Mike > > At 11:15 PM 11/11/2003 -0500, Xiaotao Wu wrote: > >I think we should not explicitly mention 'queue' in the requirement > >document. > > > >'queue' is just one way of implementing the collection for floor > >requests. How to define the queue and how to operate the queue is > >implementation issues. It should not be explicitly mentioned in the > >protocol. > > > >In our outdated draft draft-wu-sipping-floor-control-04.txt, we > >defined several queue operations for floor requests. Now I felt that to > >have the queue operations defined in a floor control protocol makes the > >protocol too complicated. > > > >I think a better way to represent the order of the requests is to use > >priority value for the requests. The priority value is just optional. > >In fact, for many common usages, we don't need to use the priority value > >to sort the requests. > > > >(1) for FIFO, time-stamp can be used to sort > >(2) for random, (like in a big conference, it does not make sense to pick > >a questioner based on who raise the hand first), no order at all > >(3) for chair-controlled, unless the other participants also want to see > >the order, the chair can keep the collection of requests locally on > >chair's UA, and there is no need to have queue operations between the > >chair and the conference server. > > > >If we do want to have the sorted collection on conference server and > >allows the chair to freely change the order, the chair can change the > >priority value of a request and the order can be changed. The participants > >can be notified of the priority value change and re-order their list. > > > >I think queue should not be explicitly mentioned. Otherwise, we need > >also mention the operations of the queue and make the protocol > >complicated. > > > >Thanks! > > > >-Xiaotao > > > >=========================================================== > >Name : Xiaotao Wu > >Email : xiaotaow@cs.columbia.edu, xiaotaow@tsinghua.com > >Homepage : http://www.cs.columbia.edu/~xiaotaow > >Phone : (212)939-7054, Fax: (801)751-0217 > >Phone-PC : (212)939-7133 > >SIP : sip:xiaotaow@conductor.cs.columbia.edu > >Office : Room 506, Mudd building, West 120th > >=========================================================== > > > >On Tue, 11 Nov 2003, Marcus Brunner wrote: > > > > > keith, > > > > > > the queue might exist for some floor control policies (e.g. for what i > > > called the ietf model). What are the things you want to say about the > > > queue? Except to distribute for example the size and on what position a > > > certain participant is sitting. > > > > > > Marcus > > > > > > > > > > > > --On Tuesday, November 11, 2003 11:38 PM +0000 "Drage, Keith (Keith)" > > > wrote: > > > > > > > So firstly you do admit that the queue exists (when the number of people > > > > requesting the floor exceeds the number allowed to hold the floor. So I > > > > believe we can define the queue so that we can say meaningful things > > > > about it. > > > > > > > > I also believe we can at least document the impact of existing > > > > requirements on the queue, e.g. if someone requests the floor, they are > > > > added to the queue until the floor chair grants the request - that after > > > > all is just documenting what already implicitly exists in the document. > > > > > > > > The question I guess we may well differ is as to what is implementation > > > > specific, and what is actually defined in future protocol specifications > > > > as a result of requirements made in the requirements draft. I guess > > > > partly that depends on where the queue is held in relation to the floor > > > > chair. If it is in the local entity to the floor chair, then any > > > > requirements on the manipulation of the queue by the floor chair could be > > > > implementation specific. Any action by participants to see or modify the > > > > queue would have to be defined. > > > > > > > > However, I am not convinced that we are yet at the stage where we can > > > > agree that the queue is in the local entity to the floor chair, and maybe > > > > we should have some discussion about that. My input to that would be that > > > > in the wireless world, we are interested in minimising the bits on the > > > > air interface, and if centralising the queue reduces the protocol load, > > > > then we would certainly want to consider it. There is already a > > > > requirement in the requirements draft to take account of this impact. > > > > > > > > Certainly if they are in separate entities, we need requirements that > > > > cover the eventual protocol that must exist between the floor chair and > > > > queue, and it would be useful to also identify what of those exist. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > drage@lucent.com > > > > tel: +44 1793 776249 > > > > > > > >> -----Original Message----- > > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > >> Sent: 11 November 2003 16:16 > > > >> To: Drage, Keith (Keith) > > > >> Cc: xcon@ietf.org > > > >> Subject: Re: [XCON] Comment on floor control requirements > > > >> > > > >> > > > >> keith, > > > >> > > > >> > > > >> > It would appear to me that this queuing needs to be more extensively > > > >> > discussed in the above requirements document. > > > >> > > > > >> > > > >> I think there should not be any restrictions on what queuing > > > >> is needed. The > > > >> mechanisms to be standardized should be free of any of these > > > >> assumtions. > > > >> > > > >> > Firstly REQ-11 implies that the queue is first in, first out (and I > > > >> > stress that this is an implication), whereas in real life > > > >> certain users > > > >> > may preempt others in the queue. > > > >> > > > > >> > Secondly it would appear to be appropriate to have > > > >> requirements for the > > > >> > floor control chair to have requirements for manipulating > > > >> the queue, e.g. > > > >> > to designate the order of obtaining the floor, to clear the > > > >> queue and so > > > >> > on. > > > >> > > > > >> > > > >> I assume this to be implementation specific. > > > >> > > > >> > Additionally, perhaps other participants may also require > > > >> visibility of > > > >> > the queue. > > > >> > > > > >> > > > >> that is good point, In draft-brunner I called it state awareness (so > > > >> participants should be able to get information about the > > > >> current state of > > > >> the floor control mechnisms including also the queue state. > > > >> > > > >> > My proposal would therefore to update the draft to > > > >> explicitly define this > > > >> > queue concept, and then to revise the requirements to reflect the > > > >> > existence of the queue, and add requirements for the > > > >> manipulation of the > > > >> > queue. > > > >> > > > > >> > > > >> I oppose, this is really implementation/application specific > > > >> and should not > > > >> influence the design of the mechnism. > > > >> > > > >> Marcus > > > >> > > > >> > regards > > > >> > > > > >> > Keith > > > >> > > > > >> > Keith Drage > > > >> > Lucent Technologies > > > >> > drage@lucent.com > > > >> > tel: +44 1793 776249 > > > >> > > > > >> > _______________________________________________ > > > >> > XCON mailing list > > > >> > XCON@ietf.org > > > >> > https://www1.ietf.org/mailman/listinfo/xcon > > > >> > > > >> > > > >> > > > >> -------------------------------------- > > > >> Dr. Marcus Brunner > > > >> Network Laboratories > > > >> NEC Europe Ltd. > > > >> > > > >> E-Mail: brunner@ccrle.nec.de > > > >> WWW: http://www.ccrle.nec.de/ > > > >> Phone: +49 (0) 6221 905 11 29 > > > >> Mobile: +49 (0) 163 275 17 43 > > > >> personal home page: http://www.brubers.org/marcus > > > >> > > > >> > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > Phone: +49 (0) 6221 905 11 29 > > > Mobile: +49 (0) 163 275 17 43 > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > > > _______________________________________________ > > > 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 exim@www1.ietf.org Thu Nov 13 16:17:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21142 for ; Thu, 13 Nov 2003 16:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOps-000706-7K for xcon-archive@odin.ietf.org; Thu, 13 Nov 2003 16:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADLH4fv026906 for xcon-archive@odin.ietf.org; Thu, 13 Nov 2003 16:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOpq-0006zt-KZ for xcon-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 16:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21133 for ; Thu, 13 Nov 2003 16:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOpo-0005XQ-00 for xcon-web-archive@ietf.org; Thu, 13 Nov 2003 16:17:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKOpo-0005XM-00 for xcon-web-archive@ietf.org; Thu, 13 Nov 2003 16:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOpo-0006z8-K8; Thu, 13 Nov 2003 16:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOph-0006yl-0X for xcon@optimus.ietf.org; Thu, 13 Nov 2003 16:16:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21123 for ; Thu, 13 Nov 2003 16:16:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOpf-0005XD-00 for xcon@ietf.org; Thu, 13 Nov 2003 16:16:51 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKOpe-0005WM-00 for xcon@ietf.org; Thu, 13 Nov 2003 16:16:50 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hADLGJGd026991 for ; Thu, 13 Nov 2003 15:16:20 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 15:16:20 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86609@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Thu, 13 Nov 2003 15:16:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Proposed new working group items Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , (As chair) At the Minneapolis meeting, many participants expressed an interest in accepting the following documents as working group items: - draft-even-xcon-conference-scenarios-00.txt - draft-koskelainen-xcon-cpcp-reqs-01.txt - draft-koskelainen-xcon-floor-control-req-00.txt, as amended by draft-brunner-xcon-fc-issues-00.txt If anyone wishes to express an objection, please do so quickly. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Nov 13 20:07:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02638 for ; Thu, 13 Nov 2003 20:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSQR-0006jT-EK for xcon-archive@odin.ietf.org; Thu, 13 Nov 2003 20:07:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE173Or025873 for xcon-archive@odin.ietf.org; Thu, 13 Nov 2003 20:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSQR-0006jE-6s for xcon-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02575 for ; Thu, 13 Nov 2003 20:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSQP-0001eb-00 for xcon-web-archive@ietf.org; Thu, 13 Nov 2003 20:07:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKSQO-0001eY-00 for xcon-web-archive@ietf.org; Thu, 13 Nov 2003 20:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSQP-0006iU-QB; Thu, 13 Nov 2003 20:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSQ6-0006hj-Hl for xcon@optimus.ietf.org; Thu, 13 Nov 2003 20:06:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02569 for ; Thu, 13 Nov 2003 20:06:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSQ4-0001eN-00 for xcon@ietf.org; Thu, 13 Nov 2003 20:06:40 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKSQ4-0001cy-00 for xcon@ietf.org; Thu, 13 Nov 2003 20:06:40 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAE168w5018024; Thu, 13 Nov 2003 17:06:08 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-116.cisco.com [10.86.242.116]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADZ15744; Thu, 13 Nov 2003 20:06:07 -0500 (EST) Message-ID: <3FB42A7E.7080202@cisco.com> Date: Thu, 13 Nov 2003 20:06:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston , Adam Roach CC: xcon@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Draft Minutes from XCON WG, IETF58, Wed 12nov2003 15:30-17:30 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Reviewed charter milestones. Noted that this is first meeting of the WG and we're already behind. [Ed: There was an initial question about something, but I couldn't understand what was said or the answer. I think it was by Roy Radhika - something about plans for extensions to conf control.] Discussed draft-even-xcon-conference-scenarios-00. There were questions about adequacy of scenarios, especially regarding text media. * Cullen Jennings agreed to contribute some text on that subject. * On humm, agreed to accept the document as WG item. Joerg Ott discussed draft-koskelainen-xcon-floor-control-req-00. There was question by Jonathan Rosenberg about relationship to focus - not covered by document. Roni Even and Rohan Mahy also asked about positioning re the conferencing framework. (There seemed to be sentiment for better positioning of this doc, but no humm on it.) Juhe Garg raised concern with the number of protocols that conference participants must implement. Answer was that this doc is just requirements, not specification of a protocol. Nermeen Ismail asked whether participants are notified who has the floor. Answer was there is a requirement for this. Cullen Jennings asked for way for requestor to know what status is of request for floor. Marcus Brunner discussed draft-brunner-xcon-fc-issues-00. This draft asserts floor control mechanism must be independent of policy; policy is instead part of the conference application. Question by chair if this could be incorporated into the floor control requirements document. Joerg and author had discussion of fine points of this. Decided this should be taken to the mailing list. Brian Rosen expressed opinion that the requirements were verging on too much for initial work. * On humm, agreed to accept the combination of these two documents as WG doc. Hisham Khartabil presented draft-koskelainen-xcon-cpcp-reqs-01. Juhe Garg requested addition of requirement to control when a conference ends. *Hummed to adopt this as WG item. Hisham also discussed draft-koskelainen-xcon-xcap-cpcp-usage-01: asked for opinions on use of XCAP for this. The people present were not prepared to commit on this. Orit Levin presented draft-levin-xcon-cpcp-00 (apparently an alternative to draft-koskelainen-xcon-xcap-cpcp-usage-01.) She had some issues with XCAP - expressed opinion it would unduly influence schema - preferred focusing on xml schema independent of transport used to manage it - open to http, sip, soap. Discussion continued on both documents. Cullen Jennings thought things don't hang together very well yet - need more work. Alan Johnston complained that he hadn't seen anything on list about it - asserted not ready to decide on one approach vs the other - need to take this to the list. Requested people to read and comment on the requirements. * Cullen Jennings, Eric Burger, and others agreed to do so. Rohan discussed draft-mahy-xcon-media-policy-control-00. It raises issue of what level of abstraction does the wg want to work at. There was very lively discussion of this, only slightly captured here. Got to question of whether the application deals with application specific roles, and they are the subjects in intereaction with media policy, or whether the application must itself map its notion of role onto some non-application-specific notation of media streams, etc. Cullen Jennings thought roles of participants can change - wasn't sure if everybody on same page. Doesn't want it to be hard to figure out roles. He also also doesn't know how an "application" relates to the model, but apparently it is important. Nermeen Ismail reiterated desire to make policy engine unaware of significance of particular roles. Eric Burger wanted something fairly high level - gave analogy - assembly language is more flexible than Java, but wojuld prefer to use Java. Rohan and Eric debated on connections between media and conference policy. Rohan thinks there are cases where changes to role of a participant in conf policy also affect media policy. Eric says "not necessarily" - it is up to "application" to decide if both should be changed. Alan raised issue that changes to media policy must be able to be reflected back to users - need some way to reverse engineer the changes to something user meaningful. Thought that the conceptual approach was better than the logical (Rohan) approach for this. Juhe Garg wanted to remove term "roles" - focus only on "permissions". Eric really didn't like this. Rohan felt use cases are needed. Nermeen wanted better requirements. Rohan then showed a strawhorse def of a subconference - asserting it is a conversation. Brian Rosen then showed a couple of slides (jennings-xconMediaPolicyRan.pdf) of rebutal to Rohan's, asking what is the problem we are trying to solve. Asserted draft-mahy-xcon-media-policy-control-00 is too complicated, and doesn't address the problem directly. Its a language to describe media flow graphs, not one to control them. Not facilitating interoperable implementations. Brian proposed templates instead. Rohan was concerned with how to map templates for media control onto conference control. Brian gave an example of a mix-minus mixer. Said #input audio streams, #output audio streams (max) are bound at conf creation. This raised a lot of concerns from audience. People felt this was almost what Rohan was proposing. Rohan asserted that any proposal must address how it interacts with conf policy. And Cullen wanted to be sure it covers all the requirements. Jonathan didn't think it was necesssary to solve all problems as long as there is extensibility. Media policy requirements draft by Roni Even mentioned: hasn't changed since last meeting. That's it. Paul Kyzivat _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sat Nov 15 19:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26782 for ; Sat, 15 Nov 2003 19:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAtZ-0002fC-Kh for xcon-archive@odin.ietf.org; Sat, 15 Nov 2003 19:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAG0a53T010232 for xcon-archive@odin.ietf.org; Sat, 15 Nov 2003 19:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAtZ-0002ex-Cu for xcon-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 19:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26763 for ; Sat, 15 Nov 2003 19:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAtX-0000iJ-00 for xcon-web-archive@ietf.org; Sat, 15 Nov 2003 19:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALAtW-0000iF-00 for xcon-web-archive@ietf.org; Sat, 15 Nov 2003 19:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAtW-0002dQ-MU; Sat, 15 Nov 2003 19:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAsm-0002Yr-MA for xcon@optimus.ietf.org; Sat, 15 Nov 2003 19:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26731 for ; Sat, 15 Nov 2003 19:35:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAsk-0000hf-00 for xcon@ietf.org; Sat, 15 Nov 2003 19:35:14 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAsk-0000h3-00 for xcon@ietf.org; Sat, 15 Nov 2003 19:35:14 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2003 16:42:17 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAG0YfAt021644; Sat, 15 Nov 2003 16:34:41 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-104.cisco.com [10.21.64.104]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ46757; Sat, 15 Nov 2003 16:34:40 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 15 Nov 2003 16:34:39 -0800 Subject: Re: [XCON] Comment on floor control requirements From: Cullen Jennings To: Marcus Brunner , "Drage, Keith (Keith)" CC: XCON-IETF Message-ID: In-Reply-To: <14293743.1068573293@dyn134-139.ietf58.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/11/03 3:54 PM, "Marcus Brunner" wrote: > keith, > > the queue might exist for some floor control policies (e.g. for what i > called the ietf model). What are the things you want to say about the > queue? Except to distribute for example the size and on what position a > certain participant is sitting. > > Marcus > Yes, the requirements you mention above look about right... I think we needs some requirements around something sort of like a priority queue. The requirements don't need to imply anything about what order things come out of the queue but knowing things like current size and approximate relative position are pretty useful. Cullen _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Nov 16 16:26:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07843 for ; Sun, 16 Nov 2003 16:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALUPE-000618-4m for xcon-archive@odin.ietf.org; Sun, 16 Nov 2003 16:26:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAGLQ4HR023127 for xcon-archive@odin.ietf.org; Sun, 16 Nov 2003 16:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALUPD-00060w-Tp for xcon-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 16:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07839 for ; Sun, 16 Nov 2003 16:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALUPC-0003Ix-00 for xcon-web-archive@ietf.org; Sun, 16 Nov 2003 16:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALUPB-0003Iu-00 for xcon-web-archive@ietf.org; Sun, 16 Nov 2003 16:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALUPC-00060V-Et; Sun, 16 Nov 2003 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALUP8-000604-RW for xcon@optimus.ietf.org; Sun, 16 Nov 2003 16:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07832 for ; Sun, 16 Nov 2003 16:25:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALUP6-0003Il-00 for xcon@ietf.org; Sun, 16 Nov 2003 16:25:56 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ALUP6-0003IE-00 for xcon@ietf.org; Sun, 16 Nov 2003 16:25:56 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAGLPNM15524 for ; Sun, 16 Nov 2003 15:25:23 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3X1W8V>; Sun, 16 Nov 2003 21:25:21 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00A500056@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Marcus Brunner , "Drage, Keith (Keith)" Cc: xcon@ietf.org Subject: RE: [XCON] Comment on floor control requirements Date: Sun, 16 Nov 2003 21:25:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Firstly, maybe the word queue seems to be loaded with preconceptions tht were not intended. After discussion with Jorg Ott maybe a better word may be set. I am not trying to imply any sort of ordering, except that which already exists in the requirements for there to be some sort of next in line. The main thing I want to see is that the requirements become clearer by specifying that participants requesting the floor end up in this "set". Apart from that certain of the existing requirements do appear to relate to manipulating this set. It would also appear to be appropriate that we have a requirement for clearing the entire set of participants waiting for the floor, e.g. when the floor chair determines a change of subject. regards Keith > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 November 2003 23:55 > To: Drage, Keith (Keith) > Cc: xcon@ietf.org > Subject: RE: [XCON] Comment on floor control requirements > > > keith, > > the queue might exist for some floor control policies (e.g. > for what i > called the ietf model). What are the things you want to say about the > queue? Except to distribute for example the size and on what > position a > certain participant is sitting. > > Marcus > > > > --On Tuesday, November 11, 2003 11:38 PM +0000 "Drage, Keith (Keith)" > wrote: > > > So firstly you do admit that the queue exists (when the > number of people > > requesting the floor exceeds the number allowed to hold the > floor. So I > > believe we can define the queue so that we can say meaningful things > > about it. > > > > I also believe we can at least document the impact of existing > > requirements on the queue, e.g. if someone requests the > floor, they are > > added to the queue until the floor chair grants the request > - that after > > all is just documenting what already implicitly exists in > the document. > > > > The question I guess we may well differ is as to what is > implementation > > specific, and what is actually defined in future protocol > specifications > > as a result of requirements made in the requirements draft. I guess > > partly that depends on where the queue is held in relation > to the floor > > chair. If it is in the local entity to the floor chair, then any > > requirements on the manipulation of the queue by the floor > chair could be > > implementation specific. Any action by participants to see > or modify the > > queue would have to be defined. > > > > However, I am not convinced that we are yet at the stage > where we can > > agree that the queue is in the local entity to the floor > chair, and maybe > > we should have some discussion about that. My input to that > would be that > > in the wireless world, we are interested in minimising the > bits on the > > air interface, and if centralising the queue reduces the > protocol load, > > then we would certainly want to consider it. There is already a > > requirement in the requirements draft to take account of > this impact. > > > > Certainly if they are in separate entities, we need > requirements that > > cover the eventual protocol that must exist between the > floor chair and > > queue, and it would be useful to also identify what of those exist. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: 11 November 2003 16:16 > >> To: Drage, Keith (Keith) > >> Cc: xcon@ietf.org > >> Subject: Re: [XCON] Comment on floor control requirements > >> > >> > >> keith, > >> > >> > >> > It would appear to me that this queuing needs to be more > extensively > >> > discussed in the above requirements document. > >> > > >> > >> I think there should not be any restrictions on what queuing > >> is needed. The > >> mechanisms to be standardized should be free of any of these > >> assumtions. > >> > >> > Firstly REQ-11 implies that the queue is first in, first > out (and I > >> > stress that this is an implication), whereas in real life > >> certain users > >> > may preempt others in the queue. > >> > > >> > Secondly it would appear to be appropriate to have > >> requirements for the > >> > floor control chair to have requirements for manipulating > >> the queue, e.g. > >> > to designate the order of obtaining the floor, to clear the > >> queue and so > >> > on. > >> > > >> > >> I assume this to be implementation specific. > >> > >> > Additionally, perhaps other participants may also require > >> visibility of > >> > the queue. > >> > > >> > >> that is good point, In draft-brunner I called it state > awareness (so > >> participants should be able to get information about the > >> current state of > >> the floor control mechnisms including also the queue state. > >> > >> > My proposal would therefore to update the draft to > >> explicitly define this > >> > queue concept, and then to revise the requirements to reflect the > >> > existence of the queue, and add requirements for the > >> manipulation of the > >> > queue. > >> > > >> > >> I oppose, this is really implementation/application specific > >> and should not > >> influence the design of the mechnism. > >> > >> Marcus > >> > >> > regards > >> > > >> > Keith > >> > > >> > Keith Drage > >> > Lucent Technologies > >> > drage@lucent.com > >> > tel: +44 1793 776249 > >> > > >> > _______________________________________________ > >> > XCON mailing list > >> > XCON@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/xcon > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> Phone: +49 (0) 6221 905 11 29 > >> Mobile: +49 (0) 163 275 17 43 > >> personal home page: http://www.brubers.org/marcus > >> > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Nov 20 04:52:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27046 for ; Thu, 20 Nov 2003 04:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMlTp-0005Pg-Gj for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 04:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK9q37p020780 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 04:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMlTm-0005P4-Ml for xcon-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 04:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27037 for ; Thu, 20 Nov 2003 04:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMlTk-0007fM-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 04:52:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMlTk-0007fI-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 04:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMlTk-0005Oh-Vz; Thu, 20 Nov 2003 04:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMlSu-0005Ns-OR for xcon@optimus.ietf.org; Thu, 20 Nov 2003 04:51:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27018 for ; Thu, 20 Nov 2003 04:50:55 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMlSs-0007ej-00 for xcon@ietf.org; Thu, 20 Nov 2003 04:51:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMlSr-0007eY-00 for xcon@ietf.org; Thu, 20 Nov 2003 04:51:05 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK9p5626662 for ; Thu, 20 Nov 2003 11:51:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 11:51:03 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 11:51:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Nov 2003 11:51:04 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101FD58CD@esebe021.ntc.nokia.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVw== To: X-OriginalArrivalTime: 20 Nov 2003 09:51:04.0843 (UTC) FILETIME=[D04A15B0:01C3AF4B] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP requirements to support IMS Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, as the CPCP issue is one very crucial for 3GPP, I would like to = summarize some requirements from the IMS side. Please be aware that = these are not official 3G requirements, but are my personal summary. I = am the rapporteur of the technical specifications for IMS Conferencing = protocol (stage 3) and collected some of the issues raised during the = last meetings. The time frame for finishing IMS conferencing in 3GPP are quite tight = again. SIP related stuff for Conferencing is mostly done in the IMS = spec, but for CPCP there is a complete lack and we are desperately = looking for progress. The below issues should be decided on until latest = mid of February, so that we have a chance to go on with conferencing in = IMS. Here we go: - creation of a conference URI as well as of a conference-factory URI Well that's so basic - I do not want to go through all the requirements = which are already there=20 - indication that user is automatically unsubscribed from conference = event subscription when user is leaving This saves a lot of bandwidht on the air interface, as the user will = just receive a NOTIFY with a Subscription-State header set to = "terminated" that additionally indicates that it has left the conference = (two SIP messages) instead of receiving the notification about his/her = own leaving, sending a un-SUBSCRIBE, receiving another NOTIFY (6 = messages).=20 - Dial-Out lists which state that the focus should either send INVITE or = REFER to the invited user.=20 Both options (INVITE and REFER) are needed in order to allow different = charging models.=20 It is not feasable that e.g. the moderator sends the REFER requests to = the invited users, as this will put high load to the air interface = (REFER + 2 NOTIFYs =3D 6 messages per REFERED-to user) - CPCP solution must be based on XCAP The interface for Data Manipulation in 3GPP IMS is the Ut interface. = Over that the following issues will be handled: - Presence related data manipulation - CPCP=20 - Floor Control - generic data manipulation In order to have one common interface, that could also be handled by the = UE (and the related service applications in the network) in a common = way, it is highly required that all these issues are solved by one = protocol.=20 This would also gurantee common security, charging, etc. models for the = Ut interface. Please ask if you need information on the IMS related issues.=20 Thanks and best regards Georg _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Nov 20 06:44:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29681 for ; Thu, 20 Nov 2003 06:44:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnEC-00020T-Ec for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 06:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKBi48s007707 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 06:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnEC-00020E-9O for xcon-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 06:44:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29673 for ; Thu, 20 Nov 2003 06:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnE9-00018W-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 06:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMnE8-00018T-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 06:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnE8-0001yw-SB; Thu, 20 Nov 2003 06:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnDB-0001wo-QV for xcon@optimus.ietf.org; Thu, 20 Nov 2003 06:43:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29591 for ; Thu, 20 Nov 2003 06:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnD8-00016t-00 for xcon@ietf.org; Thu, 20 Nov 2003 06:42:58 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AMnD7-00016q-00 for xcon@ietf.org; Thu, 20 Nov 2003 06:42:58 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAKBgvV04550; Thu, 20 Nov 2003 12:42:57 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAKBgum16199; Thu, 20 Nov 2003 12:42:56 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA07306; Thu, 20 Nov 2003 12:42:55 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Nov 2003 12:42:54 +0100 Message-ID: From: Leis Peter To: xcon@ietf.org Cc: "'georg.mayer@nokia.com'" Subject: AW: [XCON] CPCP requirements to support IMS Date: Thu, 20 Nov 2003 12:42:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi Georg, I think XCAP is not the right decission for floor control. Floor = control certainly has some real time requirements while XCAP is a = protocol for data administration. In addition the decission to use XCAP = (over Ut interface) for floor control is not yet made within 3GPP.=20 Another issue is compression. As far as I know there is no procedure = for compression of XCAP (at least up till now). But for floor control = which might happen quite frequently during an active conference we need = a protocol that can be compressed. Peter -----Urspr=FCngliche Nachricht----- Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] Gesendet: Donnerstag, 20. November 2003 10:51 An: xcon@ietf.org Betreff: [XCON] CPCP requirements to support IMS Hello, as the CPCP issue is one very crucial for 3GPP, I would like to = summarize some requirements from the IMS side. Please be aware that = these are not official 3G requirements, but are my personal summary. I = am the rapporteur of the technical specifications for IMS Conferencing = protocol (stage 3) and collected some of the issues raised during the = last meetings. The time frame for finishing IMS conferencing in 3GPP are quite tight = again. SIP related stuff for Conferencing is mostly done in the IMS = spec, but for CPCP there is a complete lack and we are desperately = looking for progress. The below issues should be decided on until = latest mid of February, so that we have a chance to go on with = conferencing in IMS. Here we go: - creation of a conference URI as well as of a conference-factory URI Well that's so basic - I do not want to go through all the requirements = which are already there=20 - indication that user is automatically unsubscribed from conference = event subscription when user is leaving This saves a lot of bandwidht on the air interface, as the user will = just receive a NOTIFY with a Subscription-State header set to = "terminated" that additionally indicates that it has left the = conference (two SIP messages) instead of receiving the notification = about his/her own leaving, sending a un-SUBSCRIBE, receiving another = NOTIFY (6 messages).=20 - Dial-Out lists which state that the focus should either send INVITE = or REFER to the invited user.=20 Both options (INVITE and REFER) are needed in order to allow different = charging models.=20 It is not feasable that e.g. the moderator sends the REFER requests to = the invited users, as this will put high load to the air interface = (REFER + 2 NOTIFYs =3D 6 messages per REFERED-to user) - CPCP solution must be based on XCAP The interface for Data Manipulation in 3GPP IMS is the Ut interface. = Over that the following issues will be handled: - Presence related data manipulation - CPCP=20 - Floor Control - generic data manipulation In order to have one common interface, that could also be handled by = the UE (and the related service applications in the network) in a = common way, it is highly required that all these issues are solved by = one protocol.=20 This would also gurantee common security, charging, etc. models for the = Ut interface. Please ask if you need information on the IMS related issues.=20 Thanks and best regards Georg _______________________________________________ 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 exim@www1.ietf.org Thu Nov 20 09:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07018 for ; Thu, 20 Nov 2003 09:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqDz-0008R2-IQ for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 09:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEu37c032418 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 09:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqDz-0008Qn-E7 for xcon-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06999 for ; Thu, 20 Nov 2003 09:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqDx-0004EC-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 09:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqDx-0004E7-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 09:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqDy-0008Q8-2V; Thu, 20 Nov 2003 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqD6-0008OX-Jp for xcon@optimus.ietf.org; Thu, 20 Nov 2003 09:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06974 for ; Thu, 20 Nov 2003 09:54:54 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqD4-0004DU-00 for xcon@ietf.org; Thu, 20 Nov 2003 09:55:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMqD3-0004DR-00 for xcon@ietf.org; Thu, 20 Nov 2003 09:55:06 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAKEt4622301 for ; Thu, 20 Nov 2003 16:55:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 16:55:04 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 16:55:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Thu, 20 Nov 2003 16:55:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B0FC@esebe019.ntc.nokia.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVwAKIXqw To: , X-OriginalArrivalTime: 20 Nov 2003 14:55:04.0236 (UTC) FILETIME=[47D096C0:01C3AF76] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > georg.mayer@nokia.com > Sent: 20.November.2003 11:51 > To: xcon@ietf.org > Subject: [XCON] CPCP requirements to support IMS >=20 >=20 > Hello, >=20 > as the CPCP issue is one very crucial for 3GPP, I would like=20 > to summarize some requirements from the IMS side. Please be=20 > aware that these are not official 3G requirements, but are my=20 > personal summary. I am the rapporteur of the technical=20 > specifications for IMS Conferencing protocol (stage 3) and=20 > collected some of the issues raised during the last meetings. >=20 > The time frame for finishing IMS conferencing in 3GPP are=20 > quite tight again. SIP related stuff for Conferencing is=20 > mostly done in the IMS spec, but for CPCP there is a complete=20 > lack and we are desperately looking for progress. The below=20 > issues should be decided on until latest mid of February, so=20 > that we have a chance to go on with conferencing in IMS. >=20 > Here we go: >=20 > - creation of a conference URI as well as of a conference-factory URI >=20 > Well that's so basic - I do not want to go through all the=20 > requirements which are already there=20 That's already convered in the requirements. In IMS, who will create = this conference URI? is it a requirement that the client must create it? = the server must create it? or both must be able to create it? >=20 >=20 > - indication that user is automatically unsubscribed from=20 > conference event subscription when user is leaving You would like that to be conference instance specific using CPCP? or is = this an implementation issue for conference server implementers? What I = mean is that do you see a use case for having to signal such thing in = CPCP? or will the IMS just behave as you describe below every time? If = it is the latter, then there is no need to standardise such thing. >=20 > This saves a lot of bandwidht on the air interface, as the=20 > user will just receive a NOTIFY with a Subscription-State=20 > header set to "terminated" that additionally indicates that=20 > it has left the conference (two SIP messages) instead of=20 > receiving the notification about his/her own leaving, sending=20 > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 >=20 >=20 >=20 > - Dial-Out lists which state that the focus should either=20 > send INVITE or REFER to the invited user.=20 Yes, we have discussed this before. It was supposed to be in the = requirements, but Petri must have missed it. Petri? >=20 > Both options (INVITE and REFER) are needed in order to allow=20 > different charging models.=20 >=20 > It is not feasible that e.g. the moderator sends the REFER=20 > requests to the invited users, as this will put high load to=20 > the air interface (REFER + 2 NOTIFYs =3D 6 messages per REFERED-to = user) >=20 >=20 >=20 > - CPCP solution must be based on XCAP This is a very strong requirement. We can leave that debate until we get = a general consensus of the current requirements, but others can feel = free to make their comments about this. Thanks for the comments, Hisham >=20 > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > interface. Over that the following issues will be handled: > - Presence related data manipulation > - CPCP=20 > - Floor Control > - generic data manipulation >=20 > In order to have one common interface, that could also be=20 > handled by the UE (and the related service applications in=20 > the network) in a common way, it is highly required that all=20 > these issues are solved by one protocol.=20 >=20 > This would also gurantee common security, charging, etc.=20 > models for the Ut interface. >=20 >=20 > Please ask if you need information on the IMS related issues.=20 >=20 > Thanks and best regards > Georg >=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 exim@www1.ietf.org Thu Nov 20 10:00:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07213 for ; Thu, 20 Nov 2003 10:00:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqHt-0000EW-Vx for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 10:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKF05th000876 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 10:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqHq-0000Dv-U1 for xcon-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 10:00:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07155 for ; Thu, 20 Nov 2003 09:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqHo-0004GB-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 10:00:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqHo-0004G8-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 10:00:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqHp-0000CO-CV; Thu, 20 Nov 2003 10:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqH9-0000Aj-O9 for xcon@optimus.ietf.org; Thu, 20 Nov 2003 09:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07118 for ; Thu, 20 Nov 2003 09:59:05 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqH7-0004Fd-00 for xcon@ietf.org; Thu, 20 Nov 2003 09:59:17 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMqH7-0004Fa-00 for xcon@ietf.org; Thu, 20 Nov 2003 09:59:17 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAKExFA03197 for ; Thu, 20 Nov 2003 16:59:15 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 16:59:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 16:59:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Thu, 20 Nov 2003 16:59:15 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179740D@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOvW51cukiPdXRjTR26Q2vAWOh4XgAGroLg To: , Cc: X-OriginalArrivalTime: 20 Nov 2003 14:59:15.0615 (UTC) FILETIME=[DDA5FAF0:01C3AF76] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Leis Peter > Sent: 20.November.2003 13:43 > To: xcon@ietf.org > Cc: Mayer Georg (NMP-MSW/Helsinki) > Subject: AW: [XCON] CPCP requirements to support IMS >=20 >=20 > hi Georg, >=20 > I think XCAP is not the right decission for floor control.=20 > Floor control certainly has some real time requirements while=20 > XCAP is a protocol for data administration. In addition the=20 > decission to use XCAP (over Ut interface) for floor control=20 > is not yet made within 3GPP.=20 I agree, but I think floor control is different that floor control = policy. >=20 > Another issue is compression. As far as I know there is no=20 > procedure for compression of XCAP (at least up till now). But=20 > for floor control which might happen quite frequently during=20 > an active conference we need a protocol that can be compressed. That's a HTTP issue. You can compress HTTP. I'm not sure if there = already exists a HTTP dictionary. We might also need a dictionary for = the XML document carried in HTTP (XCAP). But is this issue so important = in the first phase of this work that a requirement is needed that state = that the protocol must be compressible (if such work exists:)? Regards, Hisham >=20 >=20 > Peter >=20 > -----Urspr=FCngliche Nachricht----- > Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > Gesendet: Donnerstag, 20. November 2003 10:51 > An: xcon@ietf.org > Betreff: [XCON] CPCP requirements to support IMS >=20 >=20 > Hello, >=20 > as the CPCP issue is one very crucial for 3GPP, I would like=20 > to summarize some requirements from the IMS side. Please be=20 > aware that these are not official 3G requirements, but are my=20 > personal summary. I am the rapporteur of the technical=20 > specifications for IMS Conferencing protocol (stage 3) and=20 > collected some of the issues raised during the last meetings. >=20 > The time frame for finishing IMS conferencing in 3GPP are=20 > quite tight again. SIP related stuff for Conferencing is=20 > mostly done in the IMS spec, but for CPCP there is a complete=20 > lack and we are desperately looking for progress. The below=20 > issues should be decided on until latest mid of February, so=20 > that we have a chance to go on with conferencing in IMS. >=20 > Here we go: >=20 > - creation of a conference URI as well as of a conference-factory URI >=20 > Well that's so basic - I do not want to go through all the=20 > requirements which are already there=20 >=20 >=20 > - indication that user is automatically unsubscribed from=20 > conference event subscription when user is leaving >=20 > This saves a lot of bandwidht on the air interface, as the=20 > user will just receive a NOTIFY with a Subscription-State=20 > header set to "terminated" that additionally indicates that=20 > it has left the conference (two SIP messages) instead of=20 > receiving the notification about his/her own leaving, sending=20 > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 >=20 >=20 >=20 > - Dial-Out lists which state that the focus should either=20 > send INVITE or REFER to the invited user.=20 >=20 > Both options (INVITE and REFER) are needed in order to allow=20 > different charging models.=20 >=20 > It is not feasable that e.g. the moderator sends the REFER=20 > requests to the invited users, as this will put high load to=20 > the air interface (REFER + 2 NOTIFYs =3D 6 messages per REFERED-to = user) >=20 >=20 >=20 > - CPCP solution must be based on XCAP >=20 > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > interface. Over that the following issues will be handled: > - Presence related data manipulation > - CPCP=20 > - Floor Control > - generic data manipulation >=20 > In order to have one common interface, that could also be=20 > handled by the UE (and the related service applications in=20 > the network) in a common way, it is highly required that all=20 > these issues are solved by one protocol.=20 >=20 > This would also gurantee common security, charging, etc.=20 > models for the Ut interface. >=20 >=20 > Please ask if you need information on the IMS related issues.=20 >=20 > Thanks and best regards > Georg >=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 exim@www1.ietf.org Thu Nov 20 10:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09156 for ; Thu, 20 Nov 2003 10:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqf7-0001Vi-41 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 10:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKFO54Q005803 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 10:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqf6-0001VW-Sv for xcon-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 10:24:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09073 for ; Thu, 20 Nov 2003 10:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqf4-0004bB-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 10:24:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqf4-0004b8-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 10:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqf2-0001Uw-Sf; Thu, 20 Nov 2003 10:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqeq-0001Tr-Jf for xcon@optimus.ietf.org; Thu, 20 Nov 2003 10:23:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09058 for ; Thu, 20 Nov 2003 10:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqem-0004ak-00 for xcon@ietf.org; Thu, 20 Nov 2003 10:23:45 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMqem-0004Zj-00 for xcon@ietf.org; Thu, 20 Nov 2003 10:23:44 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25214; Thu, 20 Nov 2003 10:23:12 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09362; Thu, 20 Nov 2003 10:23:12 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 10:23:12 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B60F6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'georg.mayer@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Thu, 20 Nov 2003 10:23:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , > - creation of a conference URI as well as of a conference-factory URI > > Well that's so basic - I do not want to go through all the > requirements which are already there Creation of a conference factory URI? Is configuration good enough, or are you looking for a discovery protocol? > > > - indication that user is automatically unsubscribed from > conference event subscription when user is leaving > > This saves a lot of bandwidht on the air interface, as the > user will just receive a NOTIFY with a Subscription-State > header set to "terminated" that additionally indicates that > it has left the conference (two SIP messages) instead of > receiving the notification about his/her own leaving, sending > a un-SUBSCRIBE, receiving another NOTIFY (6 messages). This might be good idea, but you could unsubscribe and then leave, saving two messages. > > > > - Dial-Out lists which state that the focus should either > send INVITE or REFER to the invited user. > > Both options (INVITE and REFER) are needed in order to allow > different charging models. > > It is not feasable that e.g. the moderator sends the REFER > requests to the invited users, as this will put high load to > the air interface (REFER + 2 NOTIFYs = 6 messages per REFERED-to user) So, by REFER, without an existing dialog, you want to invite someone to a conference, but force him to send his own INVITE because then you charge him for an outgoing call, rather than an incoming call? Really? Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Nov 20 13:03:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16169 for ; Thu, 20 Nov 2003 13:03:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt8v-00057D-OP for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 13:03:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKI31YL019662 for xcon-archive@odin.ietf.org; Thu, 20 Nov 2003 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt8v-00056z-KZ for xcon-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 13:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16139 for ; Thu, 20 Nov 2003 13:02:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt8t-0007Iz-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 13:02:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMt8t-0007Iw-00 for xcon-web-archive@ietf.org; Thu, 20 Nov 2003 13:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt8u-00056k-K3; Thu, 20 Nov 2003 13:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt8q-00056K-R6 for xcon@optimus.ietf.org; Thu, 20 Nov 2003 13:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16133 for ; Thu, 20 Nov 2003 13:02:42 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt8o-0007Im-00 for xcon@ietf.org; Thu, 20 Nov 2003 13:02:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMt8o-0007Ij-00 for xcon@ietf.org; Thu, 20 Nov 2003 13:02:54 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAKI2rA00563 for ; Thu, 20 Nov 2003 20:02:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 20:02:52 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 20:02:53 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 20:02:53 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 20:02:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Thu, 20 Nov 2003 20:02:52 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0B73@trebe004.europe.nokia.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVwAKIXqwAAboqAA= To: , , X-OriginalArrivalTime: 20 Nov 2003 18:02:52.0957 (UTC) FILETIME=[847EF4D0:01C3AF90] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, =20 > > - Dial-Out lists which state that the focus should either=20 > > send INVITE or REFER to the invited user.=20 >=20 > Yes, we have discussed this before. It was supposed to be in=20 > the requirements, but Petri must have missed it. Petri? > This is covered already. I guess G5 should be changed to MUST. REQ-G1: It MUST be possible to define a dial-out list of users that the conference focus invites. REQ-G5: It SHOULD be possible to define list of users who the focus should refer to the conference (so that the referred users will dial in the conference). -- Petri _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 21 04:22:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06596 for ; Fri, 21 Nov 2003 04:22:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7UK-00011X-1P for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 04:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL9M3mM003934 for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 04:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7UJ-00011J-81 for xcon-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 04:22:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06590 for ; Fri, 21 Nov 2003 04:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7UG-0006oB-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 04:22:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN7UF-0006o8-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 04:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7UH-000114-1B; Fri, 21 Nov 2003 04:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7UD-00010n-D5 for xcon@optimus.ietf.org; Fri, 21 Nov 2003 04:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06587 for ; Fri, 21 Nov 2003 04:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7UA-0006o5-00 for xcon@ietf.org; Fri, 21 Nov 2003 04:21:54 -0500 Received: from [150.214.57.120] (helo=marcia.catalogix.se) by ietf-mx with esmtp (Exim 4.12) id 1AN7U9-0006nt-00 for xcon@ietf.org; Fri, 21 Nov 2003 04:21:54 -0500 Received: from catalogix.se (localhost [127.0.0.1]) by marcia.catalogix.se (Postfix) with ESMTP id 00A0E6FC17; Fri, 21 Nov 2003 10:21:18 +0100 (CET) Message-ID: <3FBDD90E.6070807@catalogix.se> Date: Fri, 21 Nov 2003 10:21:18 +0100 From: Roland Hedberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leis Peter , xcon@ietf.org Subject: Re: AW: [XCON] CPCP requirements to support IMS References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Leis Peter wrote: > I think XCAP is not the right decission for floor control. Floor control > certainly has some real time requirements while XCAP is a protocol for data > administration. In addition the decission to use XCAP (over Ut interface) for > floor control is not yet made within 3GPP. > > Another issue is compression. As far as I know there is no procedure for > compression of XCAP (at least up till now). But for floor control which > might happen quite frequently during an active conference we need a protocol that can be compressed. Isn't you really putting forth that the amount of bytes moved about by CPCP should be kept lo ? If the choice was a protocol like XCAP then compression might be necessary but if another protocol was choosen then it might not be an issue. -- Roland _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 21 04:31:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06814 for ; Fri, 21 Nov 2003 04:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7d1-0001Sa-MX for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 04:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL9V3F8005608 for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 04:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7d1-0001SL-D4 for xcon-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 04:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06781 for ; Fri, 21 Nov 2003 04:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7cy-0006t3-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 04:31:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN7cy-0006t0-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 04:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7d0-0001RA-4c; Fri, 21 Nov 2003 04:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7ch-0001Me-RZ for xcon@optimus.ietf.org; Fri, 21 Nov 2003 04:30:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06763 for ; Fri, 21 Nov 2003 04:30:29 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7cd-0006sp-00 for xcon@ietf.org; Fri, 21 Nov 2003 04:30:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AN7cd-0006sm-00 for xcon@ietf.org; Fri, 21 Nov 2003 04:30:39 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAL9Uc611137 for ; Fri, 21 Nov 2003 11:30:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 11:30:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 11:30:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: AW: [XCON] CPCP requirements to support IMS Date: Fri, 21 Nov 2003 11:30:38 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179741D@esebe019.ntc.nokia.com> Thread-Topic: AW: [XCON] CPCP requirements to support IMS Thread-Index: AcOwEPtK9tqaWYv4TbK3U+8u9nUeOAAAPBHw To: , , X-OriginalArrivalTime: 21 Nov 2003 09:30:38.0649 (UTC) FILETIME=[1FD57A90:01C3B012] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Roland Hedberg > Sent: 21.November.2003 11:21 > To: Leis Peter; xcon@ietf.org > Subject: Re: AW: [XCON] CPCP requirements to support IMS >=20 >=20 > Leis Peter wrote: >=20 > > I think XCAP is not the right decission for floor control.=20 > Floor control=20 > > certainly has some real time requirements while XCAP is a protocol=20 > for data > > administration. In addition the decission to use XCAP (over Ut=20 > interface) for > > floor control is not yet made within 3GPP. > >=20 > > Another issue is compression. As far as I know there is no=20 > procedure for=20 > > compression of XCAP (at least up till now). But for floor=20 > control which > > might happen quite frequently during an active conference=20 > we need a=20 > protocol that can be compressed. >=20 > Isn't you really putting forth that the amount of bytes moved=20 > about by=20 > CPCP should be kept lo ? > If the choice was a protocol like XCAP then compression might be=20 > necessary but if another protocol was choosen then it might=20 > not be an issue. The issue will only go away if you choose a binary protocol. Choosing = any text based protocol will introduce the same issue. Regards, Hisham=20 >=20 > -- Roland >=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 From exim@www1.ietf.org Fri Nov 21 04:48:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07406 for ; Fri, 21 Nov 2003 04:48:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7u0-0002tN-E6 for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 04:48:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL9ma8G011109 for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 04:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7tz-0002t3-4a for xcon-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 04:48:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07383 for ; Fri, 21 Nov 2003 04:48:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7tw-0007CW-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 04:48:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN7tv-0007C9-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 04:48:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7tS-0002rG-GL; Fri, 21 Nov 2003 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7t0-0002pa-Ov for xcon@optimus.ietf.org; Fri, 21 Nov 2003 04:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07365 for ; Fri, 21 Nov 2003 04:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7sx-0007Bx-00 for xcon@ietf.org; Fri, 21 Nov 2003 04:47:31 -0500 Received: from [150.214.57.120] (helo=marcia.catalogix.se) by ietf-mx with esmtp (Exim 4.12) id 1AN7sx-0007BO-00 for xcon@ietf.org; Fri, 21 Nov 2003 04:47:31 -0500 Received: from catalogix.se (localhost [127.0.0.1]) by marcia.catalogix.se (Postfix) with ESMTP id A58A46FC17; Fri, 21 Nov 2003 10:46:53 +0100 (CET) Message-ID: <3FBDDF0D.4080104@catalogix.se> Date: Fri, 21 Nov 2003 10:46:53 +0100 From: Roland Hedberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Cc: peter.leis@siemens.com, xcon@ietf.org Subject: Re: AW: [XCON] CPCP requirements to support IMS References: <2038BCC78B1AD641891A0D1AE133DBB70179741D@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179741D@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >> >>Isn't you really putting forth that the amount of bytes moved >>about by CPCP should be kept lo ? >>If the choice was a protocol like XCAP then compression might be >>necessary but if another protocol was choosen then it might >>not be an issue. > > > The issue will only go away if you choose a binary protocol. > Choosing any text based protocol will introduce the same issue. Not going into details here but not all text based protocols are as volumnious as the XML based. Still, the requirement should be about the size and not about compression or not. That might be an issue but only if a talkative protocol was choosen for other reasons. -- Roland _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 21 11:22:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19869 for ; Fri, 21 Nov 2003 11:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE2l-0000K1-3K for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 11:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGM3R3001231 for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 11:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE2k-0000Jm-TJ for xcon-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 11:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19856 for ; Fri, 21 Nov 2003 11:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANE2k-0004Pt-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 11:22:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANE2j-0004Pp-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 11:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE2j-0000IB-6G; Fri, 21 Nov 2003 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE2C-0000HD-6B for xcon@optimus.ietf.org; Fri, 21 Nov 2003 11:21:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19809 for ; Fri, 21 Nov 2003 11:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANE2B-0004PS-00 for xcon@ietf.org; Fri, 21 Nov 2003 11:21:27 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ANE2A-0004P6-00 for xcon@ietf.org; Fri, 21 Nov 2003 11:21:26 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 21 Nov 2003 08:20:47 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Nov 2003 08:20:54 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 08:20:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: AW: [XCON] CPCP requirements to support IMS Date: Fri, 21 Nov 2003 08:18:13 -0800 Message-ID: Thread-Topic: AW: [XCON] CPCP requirements to support IMS Thread-Index: AcOwEQPIic31bBHOStavtg1Sze4B+wAOgv83 From: "Orit Levin" To: "Roland Hedberg" , "Leis Peter" , X-OriginalArrivalTime: 21 Nov 2003 16:20:54.0474 (UTC) FILETIME=[70024AA0:01C3B04B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I certainly agree that XCAP is not the way to go. That is at least for the reason mentioned below, =20 Orit. > I think XCAP is not the right decission for floor control. Floor = control > certainly has some real time requirements while XCAP is a protocol for data > administration.=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Nov 21 11:56:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22002 for ; Fri, 21 Nov 2003 11:56:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEZg-0002xR-QV for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 11:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGu4Gn011363 for xcon-archive@odin.ietf.org; Fri, 21 Nov 2003 11:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEZg-0002wr-Ef for xcon-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 11:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21923 for ; Fri, 21 Nov 2003 11:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEZf-00059C-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 11:56:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANEZe-000596-00 for xcon-web-archive@ietf.org; Fri, 21 Nov 2003 11:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEZe-0002uV-I8; Fri, 21 Nov 2003 11:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEYx-0002so-0F for xcon@optimus.ietf.org; Fri, 21 Nov 2003 11:55:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21817 for ; Fri, 21 Nov 2003 11:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEYv-00057H-00 for xcon@ietf.org; Fri, 21 Nov 2003 11:55:17 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ANEYv-000564-00 for xcon@ietf.org; Fri, 21 Nov 2003 11:55:17 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALGsgE01391 for ; Fri, 21 Nov 2003 10:54:43 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XJQYP>; Fri, 21 Nov 2003 16:54:41 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF21@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'hisham.khartabil@nokia.com'" , peter.leis@siemens.com, xcon@ietf.org Cc: georg.mayer@nokia.com Subject: RE: [XCON] CPCP requirements to support IMS Date: Fri, 21 Nov 2003 16:54:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Which functionality is floor control policy. As far as I understand the conferencing framework document, we have - conference control policy protocol, which in itself is divided into: - membership policy - media policy and - floor control I have not seen any mention of floor control policy. I believe = requirements concerning creation and removal of floors are now = considered to be CPCP, but I am not sure where they fall in the above = divisions. The floor control requirements already contain REQ-15=09 "Bandwidth and terminal limitations SHOULD be taken into account in = order to ensure that floor control can be efficiently used in mobile = environments." In order to meet the very immediate response needs of floor control, = for 3GPP2 I would understand that floor control really needs to sit in = their short data bursts, which has a limit of something like 50 octets. = When I give the floor to someone, I certainly want them to be able to = start speaking almost immediately. When I take the floor away from = someone, I absolutely do not want them to continue for another 10 = sentences (assuming they were speaking in sentences in the first = place!!!!). At this moment in time it is premature to make any decisions about = protocol, but I would certainly believe that we retain the flexibility = to choose a different protocol for each of the above, based on = different underlying requirements. If we choose the same protocol for = membership policy as for resource list management in presence, then it = will be because the requirements are similar. regards Keith > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 20 November 2003 14:59 > To: peter.leis@siemens.com; xcon@ietf.org > Cc: georg.mayer@nokia.com > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Leis Peter > > Sent: 20.November.2003 13:43 > > To: xcon@ietf.org > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > Subject: AW: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > hi Georg, > >=20 > > I think XCAP is not the right decission for floor control.=20 > > Floor control certainly has some real time requirements while=20 > > XCAP is a protocol for data administration. In addition the=20 > > decission to use XCAP (over Ut interface) for floor control=20 > > is not yet made within 3GPP.=20 >=20 > I agree, but I think floor control is different that floor=20 > control policy. >=20 > >=20 > > Another issue is compression. As far as I know there is no=20 > > procedure for compression of XCAP (at least up till now). But=20 > > for floor control which might happen quite frequently during=20 > > an active conference we need a protocol that can be compressed. >=20 > That's a HTTP issue. You can compress HTTP. I'm not sure if=20 > there already exists a HTTP dictionary. We might also need a=20 > dictionary for the XML document carried in HTTP (XCAP). But=20 > is this issue so important in the first phase of this work=20 > that a requirement is needed that state that the protocol=20 > must be compressible (if such work exists:)? >=20 > Regards, > Hisham >=20 > >=20 > >=20 > > Peter > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > Gesendet: Donnerstag, 20. November 2003 10:51 > > An: xcon@ietf.org > > Betreff: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Hello, > >=20 > > as the CPCP issue is one very crucial for 3GPP, I would like=20 > > to summarize some requirements from the IMS side. Please be=20 > > aware that these are not official 3G requirements, but are my=20 > > personal summary. I am the rapporteur of the technical=20 > > specifications for IMS Conferencing protocol (stage 3) and > > collected some of the issues raised during the last meetings. > >=20 > > The time frame for finishing IMS conferencing in 3GPP are=20 > > quite tight again. SIP related stuff for Conferencing is=20 > > mostly done in the IMS spec, but for CPCP there is a complete=20 > > lack and we are desperately looking for progress. The below=20 > > issues should be decided on until latest mid of February, so=20 > > that we have a chance to go on with conferencing in IMS. > >=20 > > Here we go: > >=20 > > - creation of a conference URI as well as of a=20 > conference-factory URI > >=20 > > Well that's so basic - I do not want to go through all the=20 > > requirements which are already there=20 > >=20 > >=20 > > - indication that user is automatically unsubscribed from=20 > > conference event subscription when user is leaving > >=20 > > This saves a lot of bandwidht on the air interface, as the=20 > > user will just receive a NOTIFY with a Subscription-State=20 > > header set to "terminated" that additionally indicates that=20 > > it has left the conference (two SIP messages) instead of=20 > > receiving the notification about his/her own leaving, sending=20 > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 > >=20 > >=20 > >=20 > > - Dial-Out lists which state that the focus should either=20 > > send INVITE or REFER to the invited user.=20 > >=20 > > Both options (INVITE and REFER) are needed in order to allow=20 > > different charging models.=20 > >=20 > > It is not feasable that e.g. the moderator sends the REFER=20 > > requests to the invited users, as this will put high load to=20 > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > REFERED-to user) > >=20 > >=20 > >=20 > > - CPCP solution must be based on XCAP > >=20 > > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > > interface. Over that the following issues will be handled: > > - Presence related data manipulation > > - CPCP=20 > > - Floor Control > > - generic data manipulation > >=20 > > In order to have one common interface, that could also be=20 > > handled by the UE (and the related service applications in=20 > > the network) in a common way, it is highly required that all=20 > > these issues are solved by one protocol.=20 > >=20 > > This would also gurantee common security, charging, etc.=20 > > models for the Ut interface. > >=20 > >=20 > > Please ask if you need information on the IMS related issues.=20 > >=20 > > Thanks and best regards > > Georg > >=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 >=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 exim@www1.ietf.org Mon Nov 24 04:37:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01267 for ; Mon, 24 Nov 2003 04:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOD9T-0004ok-Tj for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 04:37:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO9b35x018515 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 04:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOD9S-0004oQ-PC for xcon-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 04:37:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01253 for ; Mon, 24 Nov 2003 04:36:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOD9P-00019q-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 04:36:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOD9P-00019m-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 04:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOD9Q-0004ny-LV; Mon, 24 Nov 2003 04:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOD9P-0004nY-6c for xcon@optimus.ietf.org; Mon, 24 Nov 2003 04:36:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01248 for ; Mon, 24 Nov 2003 04:36:44 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOD9L-00019j-00 for xcon@ietf.org; Mon, 24 Nov 2003 04:36:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOD9K-00019U-00 for xcon@ietf.org; Mon, 24 Nov 2003 04:36:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAO9as606730 for ; Mon, 24 Nov 2003 11:36:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 11:36:53 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 11:36:53 +0200 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: AW: [XCON] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 Nov 2003 11:36:53 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101FD59E5@esebe021.ntc.nokia.com> Thread-Topic: AW: [XCON] CPCP requirements to support IMS Thread-Index: AcOwEQPIic31bBHOStavtg1Sze4B+wAOgv83AGv8f9A= To: , , , X-OriginalArrivalTime: 24 Nov 2003 09:36:53.0502 (UTC) FILETIME=[7E80C1E0:01C3B26E] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, I also agree that the protocol for floor control needs further = investigation. Nevertheless my initial mail was about CPCP and using = XCAP for that. Good to hear nothing against that proposal. Regards Georg > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Orit Levin > Sent: 21 November, 2003 18:18 > To: Roland Hedberg; Leis Peter; xcon@ietf.org > Subject: RE: AW: [XCON] CPCP requirements to support IMS >=20 >=20 > I certainly agree that XCAP is not the way to go. > That is at least for the reason mentioned below, > =20 > Orit. >=20 >=20 > > I think XCAP is not the right decission for floor control.=20 > Floor control > > certainly has some real time requirements while XCAP is a protocol > for data > > administration.=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 From exim@www1.ietf.org Mon Nov 24 04:50:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01620 for ; Mon, 24 Nov 2003 04:50:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODM6-0005uX-Vt for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 04:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO9o6mh022720 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 04:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODM6-0005u4-Du for xcon-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 04:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01589 for ; Mon, 24 Nov 2003 04:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODM3-0001Kg-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 04:50:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AODM2-0001Kc-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 04:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODM5-0005tW-24; Mon, 24 Nov 2003 04:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODLH-0005ry-6I for xcon@optimus.ietf.org; Mon, 24 Nov 2003 04:49:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01578 for ; Mon, 24 Nov 2003 04:48:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODLD-0001KA-00 for xcon@ietf.org; Mon, 24 Nov 2003 04:49:11 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AODLD-0001K7-00 for xcon@ietf.org; Mon, 24 Nov 2003 04:49:11 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAO9nC623722 for ; Mon, 24 Nov 2003 11:49:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 11:49:10 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 11:49:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 11:49:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: [XCON] CPCP requirements to support IMS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Nov 2003 11:49:10 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B103@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOwUDhOQ7rNwsg/RrCtAW2TuLJIVACHuMZA To: , , Cc: X-OriginalArrivalTime: 24 Nov 2003 09:49:10.0806 (UTC) FILETIME=[35F86B60:01C3B270] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I see the following for floor control policy, which is not floor = control. - Does the Conference have floor control or not - Is the conference floor control moderator-driven by human or First = come first serve by automata. - How many users can have the floor at one time. - If automata driven, how long is the maximum time a user can ask for = floor. There might be other floor control policy type requirements. This list = is just from the top of my head. Regards, Hisham > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 21.November.2003 18:55 > To: Khartabil Hisham (NMP-MSW/Helsinki); peter.leis@siemens.com; > xcon@ietf.org > Cc: Mayer Georg (NMP-MSW/Helsinki) > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Which functionality is floor control policy. >=20 > As far as I understand the conferencing framework document, we have >=20 > - conference control policy protocol, which in itself is=20 > divided into: > - membership policy > - media policy >=20 > and > - floor control >=20 > I have not seen any mention of floor control policy. I=20 > believe requirements concerning creation and removal of=20 > floors are now considered to be CPCP, but I am not sure where=20 > they fall in the above divisions. >=20 > The floor control requirements already contain REQ-15=09 > "Bandwidth and terminal limitations SHOULD be taken into=20 > account in order to ensure that floor control can be=20 > efficiently used in mobile environments." >=20 > In order to meet the very immediate response needs of floor=20 > control, for 3GPP2 I would understand that floor control=20 > really needs to sit in their short data bursts, which has a=20 > limit of something like 50 octets. When I give the floor to=20 > someone, I certainly want them to be able to start speaking=20 > almost immediately. When I take the floor away from someone,=20 > I absolutely do not want them to continue for another 10=20 > sentences (assuming they were speaking in sentences in the=20 > first place!!!!). >=20 > At this moment in time it is premature to make any decisions=20 > about protocol, but I would certainly believe that we retain=20 > the flexibility to choose a different protocol for each of=20 > the above, based on different underlying requirements. If we=20 > choose the same protocol for membership policy as for=20 > resource list management in presence, then it will be because=20 > the requirements are similar. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: 20 November 2003 14:59 > > To: peter.leis@siemens.com; xcon@ietf.org > > Cc: georg.mayer@nokia.com > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Leis Peter > > > Sent: 20.November.2003 13:43 > > > To: xcon@ietf.org > > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > > Subject: AW: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > hi Georg, > > >=20 > > > I think XCAP is not the right decission for floor control.=20 > > > Floor control certainly has some real time requirements while=20 > > > XCAP is a protocol for data administration. In addition the=20 > > > decission to use XCAP (over Ut interface) for floor control=20 > > > is not yet made within 3GPP.=20 > >=20 > > I agree, but I think floor control is different that floor=20 > > control policy. > >=20 > > >=20 > > > Another issue is compression. As far as I know there is no=20 > > > procedure for compression of XCAP (at least up till now). But=20 > > > for floor control which might happen quite frequently during=20 > > > an active conference we need a protocol that can be compressed. > >=20 > > That's a HTTP issue. You can compress HTTP. I'm not sure if=20 > > there already exists a HTTP dictionary. We might also need a=20 > > dictionary for the XML document carried in HTTP (XCAP). But=20 > > is this issue so important in the first phase of this work=20 > > that a requirement is needed that state that the protocol=20 > > must be compressible (if such work exists:)? > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > >=20 > > > Peter > > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > > Gesendet: Donnerstag, 20. November 2003 10:51 > > > An: xcon@ietf.org > > > Betreff: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > Hello, > > >=20 > > > as the CPCP issue is one very crucial for 3GPP, I would like=20 > > > to summarize some requirements from the IMS side. Please be=20 > > > aware that these are not official 3G requirements, but are my=20 > > > personal summary. I am the rapporteur of the technical=20 > > > specifications for IMS Conferencing protocol (stage 3) and=20 > > > collected some of the issues raised during the last meetings. > > >=20 > > > The time frame for finishing IMS conferencing in 3GPP are=20 > > > quite tight again. SIP related stuff for Conferencing is=20 > > > mostly done in the IMS spec, but for CPCP there is a complete=20 > > > lack and we are desperately looking for progress. The below=20 > > > issues should be decided on until latest mid of February, so=20 > > > that we have a chance to go on with conferencing in IMS. > > >=20 > > > Here we go: > > >=20 > > > - creation of a conference URI as well as of a=20 > > conference-factory URI > > >=20 > > > Well that's so basic - I do not want to go through all the=20 > > > requirements which are already there=20 > > >=20 > > >=20 > > > - indication that user is automatically unsubscribed from=20 > > > conference event subscription when user is leaving > > >=20 > > > This saves a lot of bandwidht on the air interface, as the=20 > > > user will just receive a NOTIFY with a Subscription-State=20 > > > header set to "terminated" that additionally indicates that=20 > > > it has left the conference (two SIP messages) instead of=20 > > > receiving the notification about his/her own leaving, sending=20 > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 > > >=20 > > >=20 > > >=20 > > > - Dial-Out lists which state that the focus should either=20 > > > send INVITE or REFER to the invited user.=20 > > >=20 > > > Both options (INVITE and REFER) are needed in order to allow=20 > > > different charging models.=20 > > >=20 > > > It is not feasable that e.g. the moderator sends the REFER=20 > > > requests to the invited users, as this will put high load to=20 > > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > > REFERED-to user) > > >=20 > > >=20 > > >=20 > > > - CPCP solution must be based on XCAP > > >=20 > > > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > > > interface. Over that the following issues will be handled: > > > - Presence related data manipulation > > > - CPCP=20 > > > - Floor Control > > > - generic data manipulation > > >=20 > > > In order to have one common interface, that could also be=20 > > > handled by the UE (and the related service applications in=20 > > > the network) in a common way, it is highly required that all=20 > > > these issues are solved by one protocol.=20 > > >=20 > > > This would also gurantee common security, charging, etc.=20 > > > models for the Ut interface. > > >=20 > > >=20 > > > Please ask if you need information on the IMS related issues.=20 > > >=20 > > > Thanks and best regards > > > Georg > > >=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 > >=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 From exim@www1.ietf.org Mon Nov 24 08:24:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07071 for ; Mon, 24 Nov 2003 08:24:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhe-0007eY-Ok for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODOY2B029414 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 08:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhe-0007eL-Cc for xcon-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:24:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06906 for ; Mon, 24 Nov 2003 08:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGhR-0004de-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 08:24:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOGhQ-0004dP-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 08:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhL-0007X6-QW; Mon, 24 Nov 2003 08:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGXM-00075G-Tq for xcon@optimus.ietf.org; Mon, 24 Nov 2003 08:13:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06716 for ; Mon, 24 Nov 2003 08:13:42 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGXL-0004OZ-00 for xcon@ietf.org; Mon, 24 Nov 2003 08:13:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOGXL-0004OV-00 for xcon@ietf.org; Mon, 24 Nov 2003 08:13:55 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAODDs613138 for ; Mon, 24 Nov 2003 15:13:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 15:13:53 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 15:13:53 +0200 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] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 Nov 2003 15:13:52 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101E99B7E@esebe021.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOwUDhNMp5RYvgaSRe92ZA4+sRkRwCOgnFQ To: , , , X-OriginalArrivalTime: 24 Nov 2003 13:13:53.0655 (UTC) FILETIME=[CF1E7070:01C3B28C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Keith et al, > At this moment in time it is premature to make any decisions=20 > about protocol, but I would certainly believe that we retain=20 > the flexibility to choose a different protocol for each of=20 > the above, based on different underlying requirements. If we=20 > choose the same protocol for membership policy as for=20 > resource list management in presence, then it will be because=20 > the requirements are similar. well, I would say that one of the requirements from a wireless SIP = device (regardless whether it makes use of IMS or not) is for sure to = have a small set of protocols that it needs to faciliate to be able to = make use of SIP services. Furthermore I would like to see common solutions for similar = requirements and CPCP looks very similar to the presence related data = manipulation to me. Now from the IMS perspective it would be very = valuable to have only one protocol for such issues here. We also did not = chose a different messaging or presence protocol in IMS, we used SIP for = this - so I hope we can have the same for the so-called "data = manipulation" issues. Means: As long as there is not good other reasons (such as Peter pointed = out e.g. for floor control), I see good arguments for applying XCAP for = CPCP. I think I am not the only one who agrees on that. Besides that I see that we really need to decide on a protocol for CPCP = and cannot allow ourselves to wait longer. So this is in no way = premature.=20 I do not understand how you can say it is premature. Your argumentation = in CN1 is, that IETF solutionw are not mature enough, so that 3G cannot = officially (in a TS) state that something is taken from IETF. So let's = go for IETF solutions and make them mature even in your eyes.=20 Best regards Georg > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 21 November, 2003 18:55 > To: Khartabil Hisham (NMP-MSW/Helsinki); peter.leis@siemens.com; > xcon@ietf.org > Cc: Mayer Georg (NMP-MSW/Helsinki) > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Which functionality is floor control policy. >=20 > As far as I understand the conferencing framework document, we have >=20 > - conference control policy protocol, which in itself is=20 > divided into: > - membership policy > - media policy >=20 > and > - floor control >=20 > I have not seen any mention of floor control policy. I=20 > believe requirements concerning creation and removal of=20 > floors are now considered to be CPCP, but I am not sure where=20 > they fall in the above divisions. >=20 > The floor control requirements already contain REQ-15=09 > "Bandwidth and terminal limitations SHOULD be taken into=20 > account in order to ensure that floor control can be=20 > efficiently used in mobile environments." >=20 > In order to meet the very immediate response needs of floor=20 > control, for 3GPP2 I would understand that floor control=20 > really needs to sit in their short data bursts, which has a=20 > limit of something like 50 octets. When I give the floor to=20 > someone, I certainly want them to be able to start speaking=20 > almost immediately. When I take the floor away from someone,=20 > I absolutely do not want them to continue for another 10=20 > sentences (assuming they were speaking in sentences in the=20 > first place!!!!). >=20 > At this moment in time it is premature to make any decisions=20 > about protocol, but I would certainly believe that we retain=20 > the flexibility to choose a different protocol for each of=20 > the above, based on different underlying requirements. If we=20 > choose the same protocol for membership policy as for=20 > resource list management in presence, then it will be because=20 > the requirements are similar. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: 20 November 2003 14:59 > > To: peter.leis@siemens.com; xcon@ietf.org > > Cc: georg.mayer@nokia.com > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Leis Peter > > > Sent: 20.November.2003 13:43 > > > To: xcon@ietf.org > > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > > Subject: AW: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > hi Georg, > > >=20 > > > I think XCAP is not the right decission for floor control.=20 > > > Floor control certainly has some real time requirements while=20 > > > XCAP is a protocol for data administration. In addition the=20 > > > decission to use XCAP (over Ut interface) for floor control=20 > > > is not yet made within 3GPP.=20 > >=20 > > I agree, but I think floor control is different that floor=20 > > control policy. > >=20 > > >=20 > > > Another issue is compression. As far as I know there is no=20 > > > procedure for compression of XCAP (at least up till now). But=20 > > > for floor control which might happen quite frequently during=20 > > > an active conference we need a protocol that can be compressed. > >=20 > > That's a HTTP issue. You can compress HTTP. I'm not sure if=20 > > there already exists a HTTP dictionary. We might also need a=20 > > dictionary for the XML document carried in HTTP (XCAP). But=20 > > is this issue so important in the first phase of this work=20 > > that a requirement is needed that state that the protocol=20 > > must be compressible (if such work exists:)? > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > >=20 > > > Peter > > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > > Gesendet: Donnerstag, 20. November 2003 10:51 > > > An: xcon@ietf.org > > > Betreff: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > Hello, > > >=20 > > > as the CPCP issue is one very crucial for 3GPP, I would like=20 > > > to summarize some requirements from the IMS side. Please be=20 > > > aware that these are not official 3G requirements, but are my=20 > > > personal summary. I am the rapporteur of the technical=20 > > > specifications for IMS Conferencing protocol (stage 3) and=20 > > > collected some of the issues raised during the last meetings. > > >=20 > > > The time frame for finishing IMS conferencing in 3GPP are=20 > > > quite tight again. SIP related stuff for Conferencing is=20 > > > mostly done in the IMS spec, but for CPCP there is a complete=20 > > > lack and we are desperately looking for progress. The below=20 > > > issues should be decided on until latest mid of February, so=20 > > > that we have a chance to go on with conferencing in IMS. > > >=20 > > > Here we go: > > >=20 > > > - creation of a conference URI as well as of a=20 > > conference-factory URI > > >=20 > > > Well that's so basic - I do not want to go through all the=20 > > > requirements which are already there=20 > > >=20 > > >=20 > > > - indication that user is automatically unsubscribed from=20 > > > conference event subscription when user is leaving > > >=20 > > > This saves a lot of bandwidht on the air interface, as the=20 > > > user will just receive a NOTIFY with a Subscription-State=20 > > > header set to "terminated" that additionally indicates that=20 > > > it has left the conference (two SIP messages) instead of=20 > > > receiving the notification about his/her own leaving, sending=20 > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 > > >=20 > > >=20 > > >=20 > > > - Dial-Out lists which state that the focus should either=20 > > > send INVITE or REFER to the invited user.=20 > > >=20 > > > Both options (INVITE and REFER) are needed in order to allow=20 > > > different charging models.=20 > > >=20 > > > It is not feasable that e.g. the moderator sends the REFER=20 > > > requests to the invited users, as this will put high load to=20 > > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > > REFERED-to user) > > >=20 > > >=20 > > >=20 > > > - CPCP solution must be based on XCAP > > >=20 > > > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > > > interface. Over that the following issues will be handled: > > > - Presence related data manipulation > > > - CPCP=20 > > > - Floor Control > > > - generic data manipulation > > >=20 > > > In order to have one common interface, that could also be=20 > > > handled by the UE (and the related service applications in=20 > > > the network) in a common way, it is highly required that all=20 > > > these issues are solved by one protocol.=20 > > >=20 > > > This would also gurantee common security, charging, etc.=20 > > > models for the Ut interface. > > >=20 > > >=20 > > > Please ask if you need information on the IMS related issues.=20 > > >=20 > > > Thanks and best regards > > > Georg > > >=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 > >=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 From exim@www1.ietf.org Mon Nov 24 12:15:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16858 for ; Mon, 24 Nov 2003 12:15:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKIh-0001yi-H5 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 12:15:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHF3lK007601 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 12:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKIh-0001yS-Bf for xcon-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:15:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16850 for ; Mon, 24 Nov 2003 12:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKIf-0000da-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 12:15:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKIf-0000dX-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 12:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKIg-0001y7-0G; Mon, 24 Nov 2003 12:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKIZ-0001xZ-S7 for xcon@optimus.ietf.org; Mon, 24 Nov 2003 12:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16828 for ; Mon, 24 Nov 2003 12:14:39 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKIY-0000d5-00 for xcon@ietf.org; Mon, 24 Nov 2003 12:14:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOKIX-0000d2-00 for xcon@ietf.org; Mon, 24 Nov 2003 12:14:53 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOHEq605253 for ; Mon, 24 Nov 2003 19:14:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 19:14:52 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 19:14:52 +0200 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: AW: [XCON] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 Nov 2003 19:14:51 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101E99B92@esebe021.ntc.nokia.com> Thread-Topic: AW: [XCON] CPCP requirements to support IMS Thread-Index: AcOwEPZL3ZXqwo8yRt61kZUkfQV3hACnVcdw To: , , X-OriginalArrivalTime: 24 Nov 2003 17:14:52.0082 (UTC) FILETIME=[79035120:01C3B2AE] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, just to clarify - I think Peters comment was on floor control, not on = CPCP. So I think Rolands comment=20 > Isn't you really putting forth that the amount of bytes moved=20 > about by=20 > CPCP should be kept lo ? as floor control protocol realted, not CPCP related. Best regards Georg > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Roland Hedberg > Sent: 21 November, 2003 11:21 > To: Leis Peter; xcon@ietf.org > Subject: Re: AW: [XCON] CPCP requirements to support IMS >=20 >=20 > Leis Peter wrote: >=20 > > I think XCAP is not the right decission for floor control.=20 > Floor control=20 > > certainly has some real time requirements while XCAP is a protocol=20 > for data > > administration. In addition the decission to use XCAP (over Ut=20 > interface) for > > floor control is not yet made within 3GPP. > >=20 > > Another issue is compression. As far as I know there is no=20 > procedure for=20 > > compression of XCAP (at least up till now). But for floor=20 > control which > > might happen quite frequently during an active conference=20 > we need a=20 > protocol that can be compressed. >=20 > Isn't you really putting forth that the amount of bytes moved=20 > about by=20 > CPCP should be kept lo ? > If the choice was a protocol like XCAP then compression might be=20 > necessary but if another protocol was choosen then it might=20 > not be an issue. >=20 > -- Roland >=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 From exim@www1.ietf.org Mon Nov 24 12:23:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17223 for ; Mon, 24 Nov 2003 12:23:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKQQ-00028q-Lc for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 12:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHN2xq008226 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 12:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKQQ-00028b-GS for xcon-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17208 for ; Mon, 24 Nov 2003 12:22:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKQP-0000nl-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 12:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKQO-0000nh-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 12:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKQP-000281-5X; Mon, 24 Nov 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKQ1-00027l-KC for xcon@optimus.ietf.org; Mon, 24 Nov 2003 12:22:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17157 for ; Mon, 24 Nov 2003 12:22:20 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKPy-0000ml-00 for xcon@ietf.org; Mon, 24 Nov 2003 12:22:34 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOKPx-0000md-00 for xcon@ietf.org; Mon, 24 Nov 2003 12:22:33 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOHMWA01845 for ; Mon, 24 Nov 2003 19:22:32 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 19:22:32 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 19:22:31 +0200 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] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 Nov 2003 19:22:30 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101E99B95@esebe021.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOvelqv2XdM+SNBTJyDxV6VQ2dRswDNHI1Q To: , X-OriginalArrivalTime: 24 Nov 2003 17:22:31.0018 (UTC) FILETIME=[8A8F64A0:01C3B2AF] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Brian et al, thanks for the comments and sorry for the late response! > Creation of a conference factory URI? Is configuration good=20 > enough, or > are you looking for a discovery protocol? There should be a possiblity that the user can request a URI, by which = (when used in INVITE) a conference gets created. Thinking about it = again, I would say it is not important whether it is a conference or a = conference-factory URI. > This might be good idea, but you could unsubscribe and then leave, > saving two messages. But if I unsubscribe (SUBS/200 NOT/200) and then leave, I still have = four. Having just two (NOT(S-D:terminated)/200 ) would be better ;) - = you know we are counting the bits ;) But seriously: in 3G CN1 we discussed this issue and the implicit = de-registration was a strong requirement from operator side. > So, by REFER, without an existing dialog, you want to invite > someone to a conference, but force him to send his own INVITE because > then you charge him for an outgoing call, rather than an=20 > incoming call? > Really? *blush* yes. Hope that's ok.=20 Anyhow I do not understand it as "forcing" somebody, but "offering the = possiblity". Best regards Georg > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 20 November, 2003 17:23 > To: Mayer Georg (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > > - creation of a conference URI as well as of a=20 > conference-factory URI > >=20 > > Well that's so basic - I do not want to go through all the=20 > > requirements which are already there=20 > Creation of a conference factory URI? Is configuration good=20 > enough, or > are you looking for a discovery protocol? >=20 > >=20 > >=20 > > - indication that user is automatically unsubscribed from=20 > > conference event subscription when user is leaving > >=20 > > This saves a lot of bandwidht on the air interface, as the=20 > > user will just receive a NOTIFY with a Subscription-State=20 > > header set to "terminated" that additionally indicates that=20 > > it has left the conference (two SIP messages) instead of=20 > > receiving the notification about his/her own leaving, sending=20 > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages). > This might be good idea, but you could unsubscribe and then leave, > saving two messages. > =20 > >=20 > >=20 > >=20 > > - Dial-Out lists which state that the focus should either=20 > > send INVITE or REFER to the invited user.=20 > >=20 > > Both options (INVITE and REFER) are needed in order to allow=20 > > different charging models.=20 > >=20 > > It is not feasable that e.g. the moderator sends the REFER=20 > > requests to the invited users, as this will put high load to=20 > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > REFERED-to user) > So, by REFER, without an existing dialog, you want to invite > someone to a conference, but force him to send his own INVITE because > then you charge him for an outgoing call, rather than an=20 > incoming call? > Really? >=20 > Brian=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Nov 24 12:29:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17584 for ; Mon, 24 Nov 2003 12:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKWL-0002d8-BA for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 12:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHT9HL010104 for xcon-archive@odin.ietf.org; Mon, 24 Nov 2003 12:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKWL-0002cr-2I for xcon-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:29:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17546 for ; Mon, 24 Nov 2003 12:28:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKWJ-0000v8-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 12:29:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKWC-0000v1-00 for xcon-web-archive@ietf.org; Mon, 24 Nov 2003 12:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKWD-0002aE-Dp; Mon, 24 Nov 2003 12:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKW6-0002ZI-PD for xcon@optimus.ietf.org; Mon, 24 Nov 2003 12:28:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17541 for ; Mon, 24 Nov 2003 12:28:38 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKW5-0000us-00 for xcon@ietf.org; Mon, 24 Nov 2003 12:28:53 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOKW4-0000uR-00 for xcon@ietf.org; Mon, 24 Nov 2003 12:28:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOHSo622793 for ; Mon, 24 Nov 2003 19:28:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Nov 2003 19:28:50 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 19:28:50 +0200 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] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 Nov 2003 19:28:49 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101E99B96@esebe021.ntc.nokia.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVwAKIXqwAM7T0cA= To: , X-OriginalArrivalTime: 24 Nov 2003 17:28:50.0066 (UTC) FILETIME=[6C7D8720:01C3B2B0] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hisham, thanks for the comments, I try to answer them ... > That's already convered in the requirements. In IMS, who will=20 > create this conference URI? is it a requirement that the=20 > client must create it? the server must create it? or both=20 > must be able to create it? There is no requirement that the user can say "I want the URI = abc@home.net" - so I would suggest the focus is still in charge of = giving the conf a URI-name. Nevertheless the client should be able to = indicate, that the server should create a conference URI. Sorry for my = wording. > > - indication that user is automatically unsubscribed from=20 > > conference event subscription when user is leaving > > You would like that to be conference instance specific using=20 > CPCP? or is this an implementation issue for conference=20 > server implementers?=20 > What I mean is that do you see a use=20 > case for having to signal such thing in CPCP? or will the IMS=20 > just behave as you describe below every time? If it is the=20 > latter, then there is no need to standardise such thing. Well somehow it should be configurable by the user, I'd think. = Especially if the default value is "gets automatically unsubscribed" and = the user wants to stay subscribed, to be e.g. informed about the people = in the conference.=20 > > - CPCP solution must be based on XCAP >=20 > This is a very strong requirement. We can leave that debate=20 > until we get a general consensus of the current requirements,=20 > but others can feel free to make their comments about this. I think it would be good if we start this discussion early - if we can = agree early, then it's good ;). As you might have seen in my mail to = Keith (and the group) today, there are some requirements that clearly = point in direction of XCAP. Best regards Georg > -----Original Message----- > From: Khartabil Hisham (NMP-MSW/Helsinki)=20 > Sent: 20 November, 2003 16:55 > To: Mayer Georg (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > georg.mayer@nokia.com > > Sent: 20.November.2003 11:51 > > To: xcon@ietf.org > > Subject: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Hello, > >=20 > > as the CPCP issue is one very crucial for 3GPP, I would like=20 > > to summarize some requirements from the IMS side. Please be=20 > > aware that these are not official 3G requirements, but are my=20 > > personal summary. I am the rapporteur of the technical=20 > > specifications for IMS Conferencing protocol (stage 3) and=20 > > collected some of the issues raised during the last meetings. > >=20 > > The time frame for finishing IMS conferencing in 3GPP are=20 > > quite tight again. SIP related stuff for Conferencing is=20 > > mostly done in the IMS spec, but for CPCP there is a complete=20 > > lack and we are desperately looking for progress. The below=20 > > issues should be decided on until latest mid of February, so=20 > > that we have a chance to go on with conferencing in IMS. > >=20 > > Here we go: > >=20 > > - creation of a conference URI as well as of a=20 > conference-factory URI > >=20 > > Well that's so basic - I do not want to go through all the=20 > > requirements which are already there=20 >=20 > That's already convered in the requirements. In IMS, who will=20 > create this conference URI? is it a requirement that the=20 > client must create it? the server must create it? or both=20 > must be able to create it? >=20 > >=20 > >=20 > > - indication that user is automatically unsubscribed from=20 > > conference event subscription when user is leaving >=20 > You would like that to be conference instance specific using=20 > CPCP? or is this an implementation issue for conference=20 > server implementers? What I mean is that do you see a use=20 > case for having to signal such thing in CPCP? or will the IMS=20 > just behave as you describe below every time? If it is the=20 > latter, then there is no need to standardise such thing. >=20 > >=20 > > This saves a lot of bandwidht on the air interface, as the=20 > > user will just receive a NOTIFY with a Subscription-State=20 > > header set to "terminated" that additionally indicates that=20 > > it has left the conference (two SIP messages) instead of=20 > > receiving the notification about his/her own leaving, sending=20 > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 > >=20 > >=20 > >=20 > > - Dial-Out lists which state that the focus should either=20 > > send INVITE or REFER to the invited user.=20 >=20 > Yes, we have discussed this before. It was supposed to be in=20 > the requirements, but Petri must have missed it. Petri? >=20 > >=20 > > Both options (INVITE and REFER) are needed in order to allow=20 > > different charging models.=20 > >=20 > > It is not feasible that e.g. the moderator sends the REFER=20 > > requests to the invited users, as this will put high load to=20 > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > REFERED-to user) > >=20 > >=20 > >=20 > > - CPCP solution must be based on XCAP >=20 > This is a very strong requirement. We can leave that debate=20 > until we get a general consensus of the current requirements,=20 > but others can feel free to make their comments about this. >=20 > Thanks for the comments, > Hisham >=20 > >=20 > > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > > interface. Over that the following issues will be handled: > > - Presence related data manipulation > > - CPCP=20 > > - Floor Control > > - generic data manipulation > >=20 > > In order to have one common interface, that could also be=20 > > handled by the UE (and the related service applications in=20 > > the network) in a common way, it is highly required that all=20 > > these issues are solved by one protocol.=20 > >=20 > > This would also gurantee common security, charging, etc.=20 > > models for the Ut interface. > >=20 > >=20 > > Please ask if you need information on the IMS related issues.=20 > >=20 > > Thanks and best regards > > Georg > >=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 From exim@www1.ietf.org Tue Nov 25 02:44:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07045 for ; Tue, 25 Nov 2003 02:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXrm-0001TY-Lp for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 02:44:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP7iA0R005672 for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 02:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXrl-0001TP-PG for xcon-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 02:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07031 for ; Tue, 25 Nov 2003 02:43:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOXrh-0007HU-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 02:44:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOXrh-0007HR-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 02:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXre-0001Sp-7b; Tue, 25 Nov 2003 02:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXrY-0001SP-2D for xcon@optimus.ietf.org; Tue, 25 Nov 2003 02:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07024 for ; Tue, 25 Nov 2003 02:43:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOXrU-0007H7-00 for xcon@ietf.org; Tue, 25 Nov 2003 02:43:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOXrT-0007H4-00 for xcon@ietf.org; Tue, 25 Nov 2003 02:43:51 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP7hoA10681 for ; Tue, 25 Nov 2003 09:43:50 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Nov 2003 09:43:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 09:43:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Tue, 25 Nov 2003 09:43:49 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179742D@esebe019.ntc.nokia.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVwAKIXqwAM7T0cAAHevw8A== To: , X-OriginalArrivalTime: 25 Nov 2003 07:43:49.0588 (UTC) FILETIME=[DD636140:01C3B327] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Mayer Georg (NMP-MSW/Helsinki)=20 > Sent: 24.November.2003 19:29 > To: Khartabil Hisham (NMP-MSW/Helsinki); 'xcon@ietf.org' > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Hello Hisham, >=20 > thanks for the comments, I try to answer them ... >=20 > > That's already convered in the requirements. In IMS, who will=20 > > create this conference URI? is it a requirement that the=20 > > client must create it? the server must create it? or both=20 > > must be able to create it? >=20 > There is no requirement that the user can say "I want the URI=20 > abc@home.net" - so I would suggest the focus is still in=20 > charge of giving the conf a URI-name. Nevertheless the client=20 > should be able to indicate, that the server should create a=20 > conference URI. Sorry for my wording. >=20 >=20 > > > - indication that user is automatically unsubscribed from=20 > > > conference event subscription when user is leaving > > > > You would like that to be conference instance specific using=20 > > CPCP? or is this an implementation issue for conference=20 > > server implementers?=20 > > What I mean is that do you see a use=20 > > case for having to signal such thing in CPCP? or will the IMS=20 > > just behave as you describe below every time? If it is the=20 > > latter, then there is no need to standardise such thing. >=20 > Well somehow it should be configurable by the user, I'd=20 > think. Especially if the default value is "gets automatically=20 > unsubscribed" and the user wants to stay subscribed, to be=20 > e.g. informed about the people in the conference.=20 Most participants in a conference don't have control over the conference = policy. It is the moderator's decision to set the conference policy to = terminate/not terminate a participant's conference package subscription = as soon as s/he leaves the conference. So, what I was asking is: is that = what you want? or should it be the policy of the conference server as = set by the administrator of the domain? /Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 25 05:04:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10657 for ; Tue, 25 Nov 2003 05:04:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOa39-0007ei-4Q for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 05:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPA43ck029427 for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 05:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOa38-0007eY-UN for xcon-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 05:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10633 for ; Tue, 25 Nov 2003 05:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOa35-0001Bw-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 05:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOa35-0001Bs-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 05:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOa37-0007eG-9Q; Tue, 25 Nov 2003 05:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOa2e-0007Yt-7u for xcon@optimus.ietf.org; Tue, 25 Nov 2003 05:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10618 for ; Tue, 25 Nov 2003 05:03:17 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOa2a-0001BZ-00 for xcon@ietf.org; Tue, 25 Nov 2003 05:03:29 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOa2a-0001BV-00 for xcon@ietf.org; Tue, 25 Nov 2003 05:03:28 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPA3S624250 for ; Tue, 25 Nov 2003 12:03:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Nov 2003 12:03:28 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 12:03:28 +0200 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] CPCP requirements to support IMS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 25 Nov 2003 12:03:28 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101E99BA1@esebe021.ntc.nokia.com> Thread-Topic: CPCP requirements to support IMS Thread-Index: AcOvS82U0oSgB/XHQj2tUdIe1CxMVwAKIXqwAM7T0cAAHevw8AAE6x4A To: , X-OriginalArrivalTime: 25 Nov 2003 10:03:28.0908 (UTC) FILETIME=[5FDA24C0:01C3B33B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hisham, > Most participants in a conference don't have control over the=20 > conference policy. It is the moderator's decision to set the=20 > conference policy to terminate/not terminate a participant's=20 > conference package subscription as soon as s/he leaves the=20 > conference. So, what I was asking is: is that what you want?=20 > or should it be the policy of the conference server as set by=20 > the administrator of the domain? Of course there can be a default value set by the operator. And I agree = that not each participant can set this individually, as she/he will not = be allowed to use CPCP. Nevertheless there should be a CPCP option to = change the default setting for every user individually.=20 So in general: the moderator shall be able to set this value for every = user. And in IMS we assume a default value (i.e. auto-un-subscribtion) Cheers Georg > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 25 November, 2003 09:44 > To: Mayer Georg (NMP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Mayer Georg (NMP-MSW/Helsinki)=20 > > Sent: 24.November.2003 19:29 > > To: Khartabil Hisham (NMP-MSW/Helsinki); 'xcon@ietf.org' > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Hello Hisham, > >=20 > > thanks for the comments, I try to answer them ... > >=20 > > > That's already convered in the requirements. In IMS, who will=20 > > > create this conference URI? is it a requirement that the=20 > > > client must create it? the server must create it? or both=20 > > > must be able to create it? > >=20 > > There is no requirement that the user can say "I want the URI=20 > > abc@home.net" - so I would suggest the focus is still in=20 > > charge of giving the conf a URI-name. Nevertheless the client=20 > > should be able to indicate, that the server should create a=20 > > conference URI. Sorry for my wording. > >=20 > >=20 > > > > - indication that user is automatically unsubscribed from=20 > > > > conference event subscription when user is leaving > > > > > > You would like that to be conference instance specific using=20 > > > CPCP? or is this an implementation issue for conference=20 > > > server implementers?=20 > > > What I mean is that do you see a use=20 > > > case for having to signal such thing in CPCP? or will the IMS=20 > > > just behave as you describe below every time? If it is the=20 > > > latter, then there is no need to standardise such thing. > >=20 > > Well somehow it should be configurable by the user, I'd=20 > > think. Especially if the default value is "gets automatically=20 > > unsubscribed" and the user wants to stay subscribed, to be=20 > > e.g. informed about the people in the conference.=20 >=20 > Most participants in a conference don't have control over the=20 > conference policy. It is the moderator's decision to set the=20 > conference policy to terminate/not terminate a participant's=20 > conference package subscription as soon as s/he leaves the=20 > conference. So, what I was asking is: is that what you want?=20 > or should it be the policy of the conference server as set by=20 > the administrator of the domain? >=20 > /Hisham >=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 exim@www1.ietf.org Tue Nov 25 06:37:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13504 for ; Tue, 25 Nov 2003 06:37:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObVI-0002wv-LL for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 06:37:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBbCII011323 for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 06:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObVH-0002wL-Rw for xcon-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:37:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13466 for ; Tue, 25 Nov 2003 06:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObVD-0002Qr-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 06:37:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObVC-0002Qe-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 06:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObV8-0002rt-Ib; Tue, 25 Nov 2003 06:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObUe-0002qk-DS for xcon@optimus.ietf.org; Tue, 25 Nov 2003 06:36:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13444 for ; Tue, 25 Nov 2003 06:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObUa-0002QU-00 for xcon@ietf.org; Tue, 25 Nov 2003 06:36:28 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AObUZ-0002QR-00 for xcon@ietf.org; Tue, 25 Nov 2003 06:36:27 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by manatick with esmtp (Exim 4.24) id 1AObUc-0001PM-8j for xcon@ietf.org; Tue, 25 Nov 2003 06:36:30 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAPBYsE18196 for ; Tue, 25 Nov 2003 05:34:55 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XLHC7>; Tue, 25 Nov 2003 11:34:53 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00A6F92F6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: georg.mayer@nokia.com, drage@lucent.com, hisham.khartabil@nokia.com, peter.leis@siemens.com, xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Tue, 25 Nov 2003 11:34:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail2.firewall.lucent.com id hAPBYsE18196 Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable While I agree it is fairly urgent to get a decision made on the protocol,= you started this thread with a call for checking and possibly enhancing = the requirements. If we are not going to wait for the requirements to be complete before ma= king a decision on the protocol, then there is not point in having a requ= irements phase. I submit that we should only make a decision when we have some agreement = that the requirements are reasonably stable. The only decision I saw step= ping this direction at the last IETF meeting was that the requirements dr= aft should become a WG item. regards Keith > -----Original Message----- > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > Sent: 24 November 2003 13:14 > To: drage@lucent.com; hisham.khartabil@nokia.com; > peter.leis@siemens.com; xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Hello Keith et al, >=20 > > At this moment in time it is premature to make any decisions=20 > > about protocol, but I would certainly believe that we retain=20 > > the flexibility to choose a different protocol for each of=20 > > the above, based on different underlying requirements. If we=20 > > choose the same protocol for membership policy as for=20 > > resource list management in presence, then it will be because=20 > > the requirements are similar. >=20 > well, I would say that one of the requirements from a=20 > wireless SIP device (regardless whether it makes use of IMS=20 > or not) is for sure to have a small set of protocols that it=20 > needs to faciliate to be able to make use of SIP services. >=20 > Furthermore I would like to see common solutions for similar=20 > requirements and CPCP looks very similar to the presence=20 > related data manipulation to me. Now from the IMS perspective=20 > it would be very valuable to have only one protocol for such=20 > issues here. We also did not chose a different messaging or=20 > presence protocol in IMS, we used SIP for this - so I hope we=20 > can have the same for the so-called "data manipulation" issues. >=20 > Means: As long as there is not good other reasons (such as=20 > Peter pointed out e.g. for floor control), I see good=20 > arguments for applying XCAP for CPCP. I think I am not the=20 > only one who agrees on that. >=20 > Besides that I see that we really need to decide on a=20 > protocol for CPCP and cannot allow ourselves to wait longer.=20 > So this is in no way premature.=20 >=20 > I do not understand how you can say it is premature. Your=20 > argumentation in CN1 is, that IETF solutionw are not mature=20 > enough, so that 3G cannot officially (in a TS) state that=20 > something is taken from IETF. So let's go for IETF solutions=20 > and make them mature even in your eyes.=20 >=20 > Best regards > Georg >=20 > > -----Original Message----- > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 21 November, 2003 18:55 > > To: Khartabil Hisham (NMP-MSW/Helsinki); peter.leis@siemens.com; > > xcon@ietf.org > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Which functionality is floor control policy. > >=20 > > As far as I understand the conferencing framework document, we have > >=20 > > - conference control policy protocol, which in itself is=20 > > divided into: > > - membership policy > > - media policy > >=20 > > and > > - floor control > >=20 > > I have not seen any mention of floor control policy. I=20 > > believe requirements concerning creation and removal of=20 > > floors are now considered to be CPCP, but I am not sure where=20 > > they fall in the above divisions. > >=20 > > The floor control requirements already contain REQ-15=09 > > "Bandwidth and terminal limitations SHOULD be taken into=20 > > account in order to ensure that floor control can be=20 > > efficiently used in mobile environments." > >=20 > > In order to meet the very immediate response needs of floor=20 > > control, for 3GPP2 I would understand that floor control=20 > > really needs to sit in their short data bursts, which has a=20 > > limit of something like 50 octets. When I give the floor to=20 > > someone, I certainly want them to be able to start speaking=20 > > almost immediately. When I take the floor away from someone,=20 > > I absolutely do not want them to continue for another 10=20 > > sentences (assuming they were speaking in sentences in the=20 > > first place!!!!). > >=20 > > At this moment in time it is premature to make any decisions=20 > > about protocol, but I would certainly believe that we retain=20 > > the flexibility to choose a different protocol for each of=20 > > the above, based on different underlying requirements. If we=20 > > choose the same protocol for membership policy as for=20 > > resource list management in presence, then it will be because=20 > > the requirements are similar. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: 20 November 2003 14:59 > > > To: peter.leis@siemens.com; xcon@ietf.org > > > Cc: georg.mayer@nokia.com > > > Subject: RE: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > Leis Peter > > > > Sent: 20.November.2003 13:43 > > > > To: xcon@ietf.org > > > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > > > Subject: AW: [XCON] CPCP requirements to support IMS > > > >=20 > > > >=20 > > > > hi Georg, > > > >=20 > > > > I think XCAP is not the right decission for floor control.=20 > > > > Floor control certainly has some real time requirements while=20 > > > > XCAP is a protocol for data administration. In addition the=20 > > > > decission to use XCAP (over Ut interface) for floor control=20 > > > > is not yet made within 3GPP.=20 > > >=20 > > > I agree, but I think floor control is different that floor=20 > > > control policy. > > >=20 > > > >=20 > > > > Another issue is compression. As far as I know there is no=20 > > > > procedure for compression of XCAP (at least up till now). But=20 > > > > for floor control which might happen quite frequently during=20 > > > > an active conference we need a protocol that can be compressed. > > >=20 > > > That's a HTTP issue. You can compress HTTP. I'm not sure if=20 > > > there already exists a HTTP dictionary. We might also need a=20 > > > dictionary for the XML document carried in HTTP (XCAP). But=20 > > > is this issue so important in the first phase of this work=20 > > > that a requirement is needed that state that the protocol=20 > > > must be compressible (if such work exists:)? > > >=20 > > > Regards, > > > Hisham > > >=20 > > > >=20 > > > >=20 > > > > Peter > > > >=20 > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > > > Gesendet: Donnerstag, 20. November 2003 10:51 > > > > An: xcon@ietf.org > > > > Betreff: [XCON] CPCP requirements to support IMS > > > >=20 > > > >=20 > > > > Hello, > > > >=20 > > > > as the CPCP issue is one very crucial for 3GPP, I would like=20 > > > > to summarize some requirements from the IMS side. Please be=20 > > > > aware that these are not official 3G requirements, but are my=20 > > > > personal summary. I am the rapporteur of the technical=20 > > > > specifications for IMS Conferencing protocol (stage 3) and=20 > > > > collected some of the issues raised during the last meetings. > > > >=20 > > > > The time frame for finishing IMS conferencing in 3GPP are=20 > > > > quite tight again. SIP related stuff for Conferencing is=20 > > > > mostly done in the IMS spec, but for CPCP there is a complete=20 > > > > lack and we are desperately looking for progress. The below=20 > > > > issues should be decided on until latest mid of February, so=20 > > > > that we have a chance to go on with conferencing in IMS. > > > >=20 > > > > Here we go: > > > >=20 > > > > - creation of a conference URI as well as of a=20 > > > conference-factory URI > > > >=20 > > > > Well that's so basic - I do not want to go through all the=20 > > > > requirements which are already there=20 > > > >=20 > > > >=20 > > > > - indication that user is automatically unsubscribed from=20 > > > > conference event subscription when user is leaving > > > >=20 > > > > This saves a lot of bandwidht on the air interface, as the=20 > > > > user will just receive a NOTIFY with a Subscription-State=20 > > > > header set to "terminated" that additionally indicates that=20 > > > > it has left the conference (two SIP messages) instead of=20 > > > > receiving the notification about his/her own leaving, sending=20 > > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 > > > >=20 > > > >=20 > > > >=20 > > > > - Dial-Out lists which state that the focus should either=20 > > > > send INVITE or REFER to the invited user.=20 > > > >=20 > > > > Both options (INVITE and REFER) are needed in order to allow=20 > > > > different charging models.=20 > > > >=20 > > > > It is not feasable that e.g. the moderator sends the REFER=20 > > > > requests to the invited users, as this will put high load to=20 > > > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > > > REFERED-to user) > > > >=20 > > > >=20 > > > >=20 > > > > - CPCP solution must be based on XCAP > > > >=20 > > > > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > > > > interface. Over that the following issues will be handled: > > > > - Presence related data manipulation > > > > - CPCP=20 > > > > - Floor Control > > > > - generic data manipulation > > > >=20 > > > > In order to have one common interface, that could also be=20 > > > > handled by the UE (and the related service applications in=20 > > > > the network) in a common way, it is highly required that all=20 > > > > these issues are solved by one protocol.=20 > > > >=20 > > > > This would also gurantee common security, charging, etc.=20 > > > > models for the Ut interface. > > > >=20 > > > >=20 > > > > Please ask if you need information on the IMS related issues.=20 > > > >=20 > > > > Thanks and best regards > > > > Georg > > > >=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 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 25 06:49:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14097 for ; Tue, 25 Nov 2003 06:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObgp-0003s5-6R for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 06:49:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBn7ub014875 for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 06:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObgp-0003rq-1h for xcon-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14058 for ; Tue, 25 Nov 2003 06:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObgg-0002gp-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 06:48:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObgf-0002gk-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 06:48:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObgj-0003p3-58; Tue, 25 Nov 2003 06:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObgW-0003oJ-Re for xcon@optimus.ietf.org; Tue, 25 Nov 2003 06:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14036 for ; Tue, 25 Nov 2003 06:48:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObgS-0002gA-00 for xcon@ietf.org; Tue, 25 Nov 2003 06:48:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AObgR-0002g6-00 for xcon@ietf.org; Tue, 25 Nov 2003 06:48:44 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPBmi602284 for ; Tue, 25 Nov 2003 13:48:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 13:48:43 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 13:48:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Tue, 25 Nov 2003 13:48:44 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797438@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOzSCtPQS/FafrvTlGTh0E/3W880QAAbzig To: , , , X-OriginalArrivalTime: 25 Nov 2003 11:48:44.0885 (UTC) FILETIME=[1477C050:01C3B34A] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ok, so can we get some comments or the requirements as soon as possible = from interested parties :) Thanks, Hisham > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 25.November.2003 13:35 > To: Mayer Georg (NMP-MSW/Helsinki); drage@lucent.com; Khartabil Hisham > (NMP-MSW/Helsinki); peter.leis@siemens.com; xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > While I agree it is fairly urgent to get a decision made on=20 > the protocol, you started this thread with a call for=20 > checking and possibly enhancing the requirements. >=20 > If we are not going to wait for the requirements to be=20 > complete before making a decision on the protocol, then there=20 > is not point in having a requirements phase. >=20 > I submit that we should only make a decision when we have=20 > some agreement that the requirements are reasonably stable.=20 > The only decision I saw stepping this direction at the last=20 > IETF meeting was that the requirements draft should become a WG item. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > Sent: 24 November 2003 13:14 > > To: drage@lucent.com; hisham.khartabil@nokia.com; > > peter.leis@siemens.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Hello Keith et al, > >=20 > > > At this moment in time it is premature to make any decisions=20 > > > about protocol, but I would certainly believe that we retain=20 > > > the flexibility to choose a different protocol for each of=20 > > > the above, based on different underlying requirements. If we=20 > > > choose the same protocol for membership policy as for=20 > > > resource list management in presence, then it will be because=20 > > > the requirements are similar. > >=20 > > well, I would say that one of the requirements from a=20 > > wireless SIP device (regardless whether it makes use of IMS=20 > > or not) is for sure to have a small set of protocols that it=20 > > needs to faciliate to be able to make use of SIP services. > >=20 > > Furthermore I would like to see common solutions for similar=20 > > requirements and CPCP looks very similar to the presence=20 > > related data manipulation to me. Now from the IMS perspective=20 > > it would be very valuable to have only one protocol for such=20 > > issues here. We also did not chose a different messaging or=20 > > presence protocol in IMS, we used SIP for this - so I hope we=20 > > can have the same for the so-called "data manipulation" issues. > >=20 > > Means: As long as there is not good other reasons (such as=20 > > Peter pointed out e.g. for floor control), I see good=20 > > arguments for applying XCAP for CPCP. I think I am not the=20 > > only one who agrees on that. > >=20 > > Besides that I see that we really need to decide on a=20 > > protocol for CPCP and cannot allow ourselves to wait longer.=20 > > So this is in no way premature.=20 > >=20 > > I do not understand how you can say it is premature. Your=20 > > argumentation in CN1 is, that IETF solutionw are not mature=20 > > enough, so that 3G cannot officially (in a TS) state that=20 > > something is taken from IETF. So let's go for IETF solutions=20 > > and make them mature even in your eyes.=20 > >=20 > > Best regards > > Georg > >=20 > > > -----Original Message----- > > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: 21 November, 2003 18:55 > > > To: Khartabil Hisham (NMP-MSW/Helsinki); peter.leis@siemens.com; > > > xcon@ietf.org > > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > > Subject: RE: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > Which functionality is floor control policy. > > >=20 > > > As far as I understand the conferencing framework=20 > document, we have > > >=20 > > > - conference control policy protocol, which in itself is=20 > > > divided into: > > > - membership policy > > > - media policy > > >=20 > > > and > > > - floor control > > >=20 > > > I have not seen any mention of floor control policy. I=20 > > > believe requirements concerning creation and removal of=20 > > > floors are now considered to be CPCP, but I am not sure where=20 > > > they fall in the above divisions. > > >=20 > > > The floor control requirements already contain REQ-15=09 > > > "Bandwidth and terminal limitations SHOULD be taken into=20 > > > account in order to ensure that floor control can be=20 > > > efficiently used in mobile environments." > > >=20 > > > In order to meet the very immediate response needs of floor=20 > > > control, for 3GPP2 I would understand that floor control=20 > > > really needs to sit in their short data bursts, which has a=20 > > > limit of something like 50 octets. When I give the floor to=20 > > > someone, I certainly want them to be able to start speaking=20 > > > almost immediately. When I take the floor away from someone,=20 > > > I absolutely do not want them to continue for another 10=20 > > > sentences (assuming they were speaking in sentences in the=20 > > > first place!!!!). > > >=20 > > > At this moment in time it is premature to make any decisions=20 > > > about protocol, but I would certainly believe that we retain=20 > > > the flexibility to choose a different protocol for each of=20 > > > the above, based on different underlying requirements. If we=20 > > > choose the same protocol for membership policy as for=20 > > > resource list management in presence, then it will be because=20 > > > the requirements are similar. > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: 20 November 2003 14:59 > > > > To: peter.leis@siemens.com; xcon@ietf.org > > > > Cc: georg.mayer@nokia.com > > > > Subject: RE: [XCON] CPCP requirements to support IMS > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > Behalf Of ext > > > > > Leis Peter > > > > > Sent: 20.November.2003 13:43 > > > > > To: xcon@ietf.org > > > > > Cc: Mayer Georg (NMP-MSW/Helsinki) > > > > > Subject: AW: [XCON] CPCP requirements to support IMS > > > > >=20 > > > > >=20 > > > > > hi Georg, > > > > >=20 > > > > > I think XCAP is not the right decission for floor control.=20 > > > > > Floor control certainly has some real time requirements while=20 > > > > > XCAP is a protocol for data administration. In addition the=20 > > > > > decission to use XCAP (over Ut interface) for floor control=20 > > > > > is not yet made within 3GPP.=20 > > > >=20 > > > > I agree, but I think floor control is different that floor=20 > > > > control policy. > > > >=20 > > > > >=20 > > > > > Another issue is compression. As far as I know there is no=20 > > > > > procedure for compression of XCAP (at least up till now). But=20 > > > > > for floor control which might happen quite frequently during=20 > > > > > an active conference we need a protocol that can be=20 > compressed. > > > >=20 > > > > That's a HTTP issue. You can compress HTTP. I'm not sure if=20 > > > > there already exists a HTTP dictionary. We might also need a=20 > > > > dictionary for the XML document carried in HTTP (XCAP). But=20 > > > > is this issue so important in the first phase of this work=20 > > > > that a requirement is needed that state that the protocol=20 > > > > must be compressible (if such work exists:)? > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > >=20 > > > > >=20 > > > > > Peter > > > > >=20 > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > > > > Gesendet: Donnerstag, 20. November 2003 10:51 > > > > > An: xcon@ietf.org > > > > > Betreff: [XCON] CPCP requirements to support IMS > > > > >=20 > > > > >=20 > > > > > Hello, > > > > >=20 > > > > > as the CPCP issue is one very crucial for 3GPP, I would like=20 > > > > > to summarize some requirements from the IMS side. Please be=20 > > > > > aware that these are not official 3G requirements, but are my=20 > > > > > personal summary. I am the rapporteur of the technical=20 > > > > > specifications for IMS Conferencing protocol (stage 3) and=20 > > > > > collected some of the issues raised during the last meetings. > > > > >=20 > > > > > The time frame for finishing IMS conferencing in 3GPP are=20 > > > > > quite tight again. SIP related stuff for Conferencing is=20 > > > > > mostly done in the IMS spec, but for CPCP there is a complete=20 > > > > > lack and we are desperately looking for progress. The below=20 > > > > > issues should be decided on until latest mid of February, so=20 > > > > > that we have a chance to go on with conferencing in IMS. > > > > >=20 > > > > > Here we go: > > > > >=20 > > > > > - creation of a conference URI as well as of a=20 > > > > conference-factory URI > > > > >=20 > > > > > Well that's so basic - I do not want to go through all the=20 > > > > > requirements which are already there=20 > > > > >=20 > > > > >=20 > > > > > - indication that user is automatically unsubscribed from=20 > > > > > conference event subscription when user is leaving > > > > >=20 > > > > > This saves a lot of bandwidht on the air interface, as the=20 > > > > > user will just receive a NOTIFY with a Subscription-State=20 > > > > > header set to "terminated" that additionally indicates that=20 > > > > > it has left the conference (two SIP messages) instead of=20 > > > > > receiving the notification about his/her own leaving, sending=20 > > > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages).=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > - Dial-Out lists which state that the focus should either=20 > > > > > send INVITE or REFER to the invited user.=20 > > > > >=20 > > > > > Both options (INVITE and REFER) are needed in order to allow=20 > > > > > different charging models.=20 > > > > >=20 > > > > > It is not feasable that e.g. the moderator sends the REFER=20 > > > > > requests to the invited users, as this will put high load to=20 > > > > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > > > > REFERED-to user) > > > > >=20 > > > > >=20 > > > > >=20 > > > > > - CPCP solution must be based on XCAP > > > > >=20 > > > > > The interface for Data Manipulation in 3GPP IMS is the Ut=20 > > > > > interface. Over that the following issues will be handled: > > > > > - Presence related data manipulation > > > > > - CPCP=20 > > > > > - Floor Control > > > > > - generic data manipulation > > > > >=20 > > > > > In order to have one common interface, that could also be=20 > > > > > handled by the UE (and the related service applications in=20 > > > > > the network) in a common way, it is highly required that all=20 > > > > > these issues are solved by one protocol.=20 > > > > >=20 > > > > > This would also gurantee common security, charging, etc.=20 > > > > > models for the Ut interface. > > > > >=20 > > > > >=20 > > > > > Please ask if you need information on the IMS related issues.=20 > > > > >=20 > > > > > Thanks and best regards > > > > > Georg > > > > >=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 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 25 06:57:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14356 for ; Tue, 25 Nov 2003 06:57:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOboU-0004CM-KJ for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 06:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBv2gj016132 for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 06:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOboU-0004C7-F4 for xcon-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14326 for ; Tue, 25 Nov 2003 06:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOboQ-0002sU-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 06:56:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOboP-0002sR-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 06:56:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOboT-0004Av-6J; Tue, 25 Nov 2003 06:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOboM-0004AS-MY for xcon@optimus.ietf.org; Tue, 25 Nov 2003 06:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14323 for ; Tue, 25 Nov 2003 06:56:38 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOboI-0002sI-00 for xcon@ietf.org; Tue, 25 Nov 2003 06:56:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOboH-0002sF-00 for xcon@ietf.org; Tue, 25 Nov 2003 06:56:49 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPBuoA07634 for ; Tue, 25 Nov 2003 13:56:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 13:56:48 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 13:56:47 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 13:56:47 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 13:56:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Tue, 25 Nov 2003 13:56:46 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0B83@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOzSCtPQS/FafrvTlGTh0E/3W880QAAbzigAAA4XQA= To: , , , , X-OriginalArrivalTime: 25 Nov 2003 11:56:46.0950 (UTC) FILETIME=[33CD0860:01C3B34B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm a bit worried about media policy-CPCP integration=20 and WG schedule regarding it. Currently the charter says the following: May 04 Submit Membership Manipulation Protocol for publication as PS=20 Jul 04 Submit Protocol for Media Topology Control for publication What I would like to have by May 04 is CPCP with the ability to set up = typical real-life conference, e.g. with audio codec X and centralized mixer.=20 (in most cases, this does not require overly complex topology = definition, instead something like in current SDP may be enough). Current media policy seems to be extremely complex and the RFC goal=20 is not until July. Georg can probably comment on 3GPP schedules but in any case, should we=20 adopt simple media definition in CPCP itself (or divide media=20 policy into basic and advanced parts so basic media policy=20 could be ready by May 04)? -- Petri=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Nov 25 07:53:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16005 for ; Tue, 25 Nov 2003 07:53:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcgf-0006m4-SQ for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 07:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPCr1Su026034 for xcon-archive@odin.ietf.org; Tue, 25 Nov 2003 07:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcgf-0006lp-OB for xcon-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 07:53:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16002 for ; Tue, 25 Nov 2003 07:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcge-0004DC-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 07:53:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOcge-0004D9-00 for xcon-web-archive@ietf.org; Tue, 25 Nov 2003 07:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcge-0006kc-J4; Tue, 25 Nov 2003 07:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcgc-0006kQ-Cn for xcon@optimus.ietf.org; Tue, 25 Nov 2003 07:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15999 for ; Tue, 25 Nov 2003 07:52:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcgb-0004D3-00 for xcon@ietf.org; Tue, 25 Nov 2003 07:52:57 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AOcga-0004CG-00 for xcon@ietf.org; Tue, 25 Nov 2003 07:52:56 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA17492; Tue, 25 Nov 2003 07:52:25 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA03704; Tue, 25 Nov 2003 07:52:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 07:52:25 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6113@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'georg.mayer@nokia.com'" Cc: xcon@ietf.org Subject: RE: [XCON] CPCP requirements to support IMS Date: Tue, 25 Nov 2003 07:52:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Georg I think one of us has some confusion on a conference URI vs a conference factory URI. A conference URI refers to a specific conference. If you INVITE with a conference URI, the focus will put you in the conference. One conference, one conference URI. A conference factory URI is one way to create a conference uri. You send an INVITE to the conference factory uri, and it returns a Contact which is a conference uri. There is normally only one conference factory URI per conference service, although you could imagine some kind of specialization that would create a need for more than one. I was imagining that the conference factory URI was provisioned, or provided to you via some out of band means, although I'd really like the default outgoing proxy (the one you normally discover by DHCP or multicast), to tell you what it is. So the conference factory uri is what you use to create a conference uri, and the conference uri is what you use to refer to a specific conference. Brian > -----Original Message----- > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > Sent: Monday, November 24, 2003 12:23 PM > To: Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS > > > Hello Brian et al, > > thanks for the comments and sorry for the late response! > > > Creation of a conference factory URI? Is configuration good > > enough, or > > are you looking for a discovery protocol? > > There should be a possiblity that the user can request a URI, > by which (when used in INVITE) a conference gets created. > Thinking about it again, I would say it is not important > whether it is a conference or a conference-factory URI. > > > This might be good idea, but you could unsubscribe and then leave, > > saving two messages. > > But if I unsubscribe (SUBS/200 NOT/200) and then leave, I > still have four. Having just two (NOT(S-D:terminated)/200 ) > would be better ;) - you know we are counting the bits ;) > > But seriously: in 3G CN1 we discussed this issue and the > implicit de-registration was a strong requirement from operator side. > > > > So, by REFER, without an existing dialog, you want to invite > > someone to a conference, but force him to send his own > INVITE because > > then you charge him for an outgoing call, rather than an > > incoming call? > > Really? > > *blush* yes. Hope that's ok. > Anyhow I do not understand it as "forcing" somebody, but > "offering the possiblity". > > Best regards > Georg > > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 20 November, 2003 17:23 > > To: Mayer Georg (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > > > > > > > - creation of a conference URI as well as of a > > conference-factory URI > > > > > > Well that's so basic - I do not want to go through all the > > > requirements which are already there > > Creation of a conference factory URI? Is configuration good > > enough, or > > are you looking for a discovery protocol? > > > > > > > > > > > - indication that user is automatically unsubscribed from > > > conference event subscription when user is leaving > > > > > > This saves a lot of bandwidht on the air interface, as the > > > user will just receive a NOTIFY with a Subscription-State > > > header set to "terminated" that additionally indicates that > > > it has left the conference (two SIP messages) instead of > > > receiving the notification about his/her own leaving, sending > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages). > > This might be good idea, but you could unsubscribe and then leave, > > saving two messages. > > > > > > > > > > > > > > - Dial-Out lists which state that the focus should either > > > send INVITE or REFER to the invited user. > > > > > > Both options (INVITE and REFER) are needed in order to allow > > > different charging models. > > > > > > It is not feasable that e.g. the moderator sends the REFER > > > requests to the invited users, as this will put high load to > > > the air interface (REFER + 2 NOTIFYs = 6 messages per > > REFERED-to user) > > So, by REFER, without an existing dialog, you want to invite > > someone to a conference, but force him to send his own > INVITE because > > then you charge him for an outgoing call, rather than an > > incoming call? > > Really? > > > > Brian > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Nov 27 11:35:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12293 for ; Thu, 27 Nov 2003 11:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APP6e-0000Jr-He for xcon-archive@odin.ietf.org; Thu, 27 Nov 2003 11:35:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARGZ40E001224 for xcon-archive@odin.ietf.org; Thu, 27 Nov 2003 11:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APP6e-0000Jf-Bz for xcon-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 11:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12283 for ; Thu, 27 Nov 2003 11:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APP6d-0002UE-00 for xcon-web-archive@ietf.org; Thu, 27 Nov 2003 11:35:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APP6c-0002UA-00 for xcon-web-archive@ietf.org; Thu, 27 Nov 2003 11:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APP6b-0000J7-1A; Thu, 27 Nov 2003 11:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APP5j-0000IW-3p for xcon@optimus.ietf.org; Thu, 27 Nov 2003 11:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12260 for ; Thu, 27 Nov 2003 11:33:53 -0500 (EST) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APP5h-0002TY-00 for xcon@ietf.org; Thu, 27 Nov 2003 11:34:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1APP5h-0002TU-00 for xcon@ietf.org; Thu, 27 Nov 2003 11:34:05 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hARGY3M26392 for ; Thu, 27 Nov 2003 18:34:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Nov 2003 18:34:03 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 18:34:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP requirements to support IMS Date: Thu, 27 Nov 2003 18:34:02 +0200 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF5101E99BC5@esebe021.ntc.nokia.com> Thread-Topic: [XCON] CPCP requirements to support IMS Thread-Index: AcOzUzUNQB+nCCwrQueh5qQQwFSBrwBsG1Gg To: Cc: X-OriginalArrivalTime: 27 Nov 2003 16:34:03.0046 (UTC) FILETIME=[44835460:01C3B504] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Brian, I think we have the same understanding. There are two more things I = would like to add: a) there may be different conferece factory URIs for different types of = conferences (e.g. for some only a restricted number of participants = might be allowed, etc.) b) if no conference resources have been reserved up till now (i.e. if = there is no participant in the conference) from the users point of view = the result of sending an INVITE with a conference factory URI or a = conference URI is identical. Of course in the case of the factory URI, = the conference URI is first created, but afterwards the conference = resources are reserved and the user becomes the first participant in it. What I meant in my mails before was, that the user should get via CPCP = aware of a URI that finally allows him to join the conference and = automatically reserve the resources for it.=20 As I said, I agree that this can be done by a normal conference URI. Good morning / good night Georg > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 25 November, 2003 14:52 > To: Mayer Georg (NMP-MSW/Helsinki) > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP requirements to support IMS >=20 >=20 > Georg >=20 > I think one of us has some confusion on a conference URI vs a=20 > conference > factory URI. >=20 > A conference URI refers to a specific conference. If you INVITE with > a conference URI, the focus will put you in the conference. =20 > One conference, > one conference URI. =20 >=20 > A conference factory URI is one way to create a conference=20 > uri. You send > an INVITE to the conference factory uri, and it returns a=20 > Contact which > is a conference uri. There is normally only one conference=20 > factory URI > per conference service, although you could imagine some kind of=20 > specialization that would create a need for more than one. I=20 > was imagining=20 > that the conference factory URI was provisioned, or provided=20 > to you via=20 > some out of band means, although I'd really like the default outgoing=20 > proxy (the one you normally discover by DHCP or multicast),=20 > to tell you=20 > what it is. >=20 > So the conference factory uri is what you use to create a=20 > conference uri, > and the conference uri is what you use to refer to a specific=20 > conference. >=20 > Brian >=20 >=20 >=20 > > -----Original Message----- > > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > > Sent: Monday, November 24, 2003 12:23 PM > > To: Brian.Rosen@marconi.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP requirements to support IMS > >=20 > >=20 > > Hello Brian et al, > >=20 > > thanks for the comments and sorry for the late response! > >=20 > > > Creation of a conference factory URI? Is configuration good=20 > > > enough, or > > > are you looking for a discovery protocol? > >=20 > > There should be a possiblity that the user can request a URI,=20 > > by which (when used in INVITE) a conference gets created.=20 > > Thinking about it again, I would say it is not important=20 > > whether it is a conference or a conference-factory URI. > >=20 > > > This might be good idea, but you could unsubscribe and then leave, > > > saving two messages. > >=20 > > But if I unsubscribe (SUBS/200 NOT/200) and then leave, I=20 > > still have four. Having just two (NOT(S-D:terminated)/200 )=20 > > would be better ;) - you know we are counting the bits ;) > >=20 > > But seriously: in 3G CN1 we discussed this issue and the=20 > > implicit de-registration was a strong requirement from=20 > operator side. > >=20 > >=20 > > > So, by REFER, without an existing dialog, you want to invite > > > someone to a conference, but force him to send his own=20 > > INVITE because > > > then you charge him for an outgoing call, rather than an=20 > > > incoming call? > > > Really? > >=20 > > *blush* yes. Hope that's ok.=20 > > Anyhow I do not understand it as "forcing" somebody, but=20 > > "offering the possiblity". > >=20 > > Best regards > > Georg > >=20 > >=20 > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 20 November, 2003 17:23 > > > To: Mayer Georg (NMP-MSW/Helsinki); xcon@ietf.org > > > Subject: RE: [XCON] CPCP requirements to support IMS > > >=20 > > >=20 > > > > - creation of a conference URI as well as of a=20 > > > conference-factory URI > > > >=20 > > > > Well that's so basic - I do not want to go through all the=20 > > > > requirements which are already there=20 > > > Creation of a conference factory URI? Is configuration good=20 > > > enough, or > > > are you looking for a discovery protocol? > > >=20 > > > >=20 > > > >=20 > > > > - indication that user is automatically unsubscribed from=20 > > > > conference event subscription when user is leaving > > > >=20 > > > > This saves a lot of bandwidht on the air interface, as the=20 > > > > user will just receive a NOTIFY with a Subscription-State=20 > > > > header set to "terminated" that additionally indicates that=20 > > > > it has left the conference (two SIP messages) instead of=20 > > > > receiving the notification about his/her own leaving, sending=20 > > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages). > > > This might be good idea, but you could unsubscribe and then leave, > > > saving two messages. > > > =20 > > > >=20 > > > >=20 > > > >=20 > > > > - Dial-Out lists which state that the focus should either=20 > > > > send INVITE or REFER to the invited user.=20 > > > >=20 > > > > Both options (INVITE and REFER) are needed in order to allow=20 > > > > different charging models.=20 > > > >=20 > > > > It is not feasable that e.g. the moderator sends the REFER=20 > > > > requests to the invited users, as this will put high load to=20 > > > > the air interface (REFER + 2 NOTIFYs =3D 6 messages per=20 > > > REFERED-to user) > > > So, by REFER, without an existing dialog, you want to invite > > > someone to a conference, but force him to send his own=20 > > INVITE because > > > then you charge him for an outgoing call, rather than an=20 > > > incoming call? > > > Really? > > >=20 > > > Brian=20 > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Nov 30 13:54:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08327 for ; Sun, 30 Nov 2003 13:54:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWhp-0007MS-Tx for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 13:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUIs5N5028287 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 13:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWhp-0007MA-P2 for xcon-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 13:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08281 for ; Sun, 30 Nov 2003 13:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQWhn-0002bM-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 13:54:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQWhm-0002bG-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 13:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWhl-0007LN-6z; Sun, 30 Nov 2003 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWgx-0007Kj-Ii for xcon@optimus.ietf.org; Sun, 30 Nov 2003 13:53:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08242 for ; Sun, 30 Nov 2003 13:52:56 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQWgv-0002ZY-00 for xcon@ietf.org; Sun, 30 Nov 2003 13:53:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQWgu-0002ZT-00 for xcon@ietf.org; Sun, 30 Nov 2003 13:53:08 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAUIr7819136 for ; Sun, 30 Nov 2003 20:53:07 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 30 Nov 2003 20:53:07 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 30 Nov 2003 20:53:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Nov 2003 20:53:07 +0200 Message-ID: Thread-Topic: CPCP - making something simple that works Thread-Index: AcO3czE7LtqIeTDgTH6+nENQf+BXvQ== To: X-OriginalArrivalTime: 30 Nov 2003 18:53:07.0576 (UTC) FILETIME=[317ACF80:01C3B773] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP - making something simple that works Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I would like to propose that XCON WG makes some descoping for CPCP = functionality in the initial phase. In my opinion the current = requirements draft contains a lot of features, that are useful, but not = necessary in the first version. I think we need to discuss on = prioritization to have any chance to meet the deadlines proposed in the = charter. Obviously the success of this approach depends on whether the WG can = agree on what would be the prioritized subset. Below I list the things = that are in my opinion the most important ones: - Conference creation and conference URI assignment (It is possible to use SIP INVITE for this in ad hoc case, but = something more permanent is definitely needed.) - Authorization rules for joining the conference (~ACL) and doing some = key operations, such as subscribing to conference state event. - Doing mass-invitations/having a dial-out list. This should include = mass-kickout functionality too. (SIP exploders are supposed to do this too, so this may not belong to = the most-important category if exploder solution turns out good, of = course we should be thinking of non-SIP session management environments = in XCON too.) - Describing a small set of conference meta-data (Subject etc.) At least I would be happy with a protocol that can initially do these = operations. Timing/scheduling etc. could be added later. This makes an = obvious requirement to the protocol that it must be extensible, and it = should be possible to determine the feature set supported by the = conference (policy) server. Comments? Do people want to go along with all possible bells and = whistles, or is there support for this descoping activity? Markus =20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Nov 30 13:54:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08328 for ; Sun, 30 Nov 2003 13:54:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWhp-0007Mg-Vv for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 13:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUIs5FP028304 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 13:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWhp-0007MG-Rb for xcon-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 13:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08283 for ; Sun, 30 Nov 2003 13:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQWhn-0002bP-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 13:54:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQWhm-0002bH-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 13:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWhl-0007LV-EM; Sun, 30 Nov 2003 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWgy-0007Ko-Ti for xcon@optimus.ietf.org; Sun, 30 Nov 2003 13:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08245 for ; Sun, 30 Nov 2003 13:52:58 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQWgw-0002Zf-00 for xcon@ietf.org; Sun, 30 Nov 2003 13:53:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AQWgw-0002Zc-00 for xcon@ietf.org; Sun, 30 Nov 2003 13:53:10 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAUIr9Y07663 for ; Sun, 30 Nov 2003 20:53:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 30 Nov 2003 20:53:09 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 30 Nov 2003 20:53:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Nov 2003 20:53:08 +0200 Message-ID: Thread-Topic: CPCP - is XCAP suitable or not Thread-Index: AcO3czIkCgBc+hYzRxWWUQcv3i78xQ== To: X-OriginalArrivalTime: 30 Nov 2003 18:53:09.0351 (UTC) FILETIME=[3289A770:01C3B773] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP - is XCAP suitable or not Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, There has been discussion on the mailing list and also in Minneapolis = whether XCAP would be a good protocol to meet CPCP requirements or not. = There is already a proposal showing how this could work by Hisham and = Petri, but maybe there needs to be some more general discussion first. = In the following I describe my understanding on the issues: XCAP is designed for data manipulation, i.e. client can manipulate XML = based information on a server. There is some limited intelligence = included in the protocol via XML schema validation and computed data. = XCAP is very suitable for operations which can be somehow modeled as = configuration/data manipulation, i.e. manipulation some state on the = server. It is less well suited for sending explicit commands to a server = in a case where the client just wants the server to do some operation = without creating more permanent state. XCAP as such lacks the abilty to = convey events describing the state of what is going on in the requested = operations (response to request needs to be sent according to HTTP = rules), but to overcome that SIP could be used. CPCP will presumably contain different types of = operations/functionality. Conference creation and URI assigment seem = equal to what is done with XCAP resource list AUID, so no problem there. = Access and privilege rule management seems equal to what is done in XCAP = presence authorization AUID, so that works too. Any parameter/metadata = setting (subject, timing, ...) is also exactly what XCAP does.=20 The main point of difficulty seems to be mass-invite/dial-out list and = mass-kick-out functionality, since this seems more like commanding than = configuring. It is however possible, even if not perhaps elegant, to = model this as data manipulation as well, if we assume that the = conference focus is an XCAP client too. It is possible to define that = dial-out list is just another list which the client can manipulate, and = the logic would be that if someone who is not currently in the = conference is included to the list he is invited. Once the invitation = attempt has been done (success or failure), the conference focus(?) may = need to remove the entry from the list to prevent the list from growing = eternally. SIP conference state event can be used by the client to = monitor the progress of the attempt. Kick-outs could be done similarly = by managing the access control. At least I didn't come up with any other type of functionality that = would be needed in CPCP. Based on this and the desire to reuse existing = protocols (XCAP is probably included in many of the clients having CPCP = in the future) I came up with two options that I would be happy with: a) Do everything with XCAP by modeling the commands as data = manipulation, probably as explained above with mass-invitation case b) Do conf creation, parameter setting, ACL management with XCAP, and = leave mass-invitations/kick-outs to some other protocol, which could be = some very simple XML-RPC thing, or indeed, SIP exploder mechanism. Obviously, there is option c) not to use XCAP at all, but I didn't come = up with a compelling reason for that. I believe that we just have to decide on which requirements to keep and = how we proceed with the protocol (XCAP or something else) before the end = of this year to have something ready at least somewhat close to the = charter deadlines. Markus _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Nov 30 14:06:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08725 for ; Sun, 30 Nov 2003 14:06:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWtO-0008B0-Da for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 14:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUJ62JP031429 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 14:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWtO-0008Aq-A1 for xcon-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 14:06:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08718 for ; Sun, 30 Nov 2003 14:05:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQWtL-0002wr-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 14:05:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQWtL-0002wm-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 14:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWtN-0008A8-8N; Sun, 30 Nov 2003 14:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQWtC-00089X-GQ for xcon@optimus.ietf.org; Sun, 30 Nov 2003 14:05:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08701 for ; Sun, 30 Nov 2003 14:05:35 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQWtA-0002wH-00 for xcon@ietf.org; Sun, 30 Nov 2003 14:05:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AQWt9-0002wD-00 for xcon@ietf.org; Sun, 30 Nov 2003 14:05:47 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAUJ5kY16870 for ; Sun, 30 Nov 2003 21:05:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 30 Nov 2003 21:05:46 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 30 Nov 2003 21:05:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP - making something simple that works Date: Sun, 30 Nov 2003 21:05:46 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> Thread-Topic: CPCP - making something simple that works Thread-Index: AcO3czE7LtqIeTDgTH6+nENQf+BXvQAAQDnA To: , X-OriginalArrivalTime: 30 Nov 2003 19:05:46.0709 (UTC) FILETIME=[F5F55050:01C3B774] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Markus.Isomaki@nokia.com > Sent: 30.November.2003 20:53 > To: xcon@ietf.org > Subject: [XCON] CPCP - making something simple that works >=20 >=20 > Hi, >=20 > I would like to propose that XCON WG makes some descoping for=20 > CPCP functionality in the initial phase. In my opinion the=20 > current requirements draft contains a lot of features, that=20 > are useful, but not necessary in the first version. I think=20 > we need to discuss on prioritization to have any chance to=20 > meet the deadlines proposed in the charter. >=20 > Obviously the success of this approach depends on whether the=20 > WG can agree on what would be the prioritized subset. Below I=20 > list the things that are in my opinion the most important ones: > - Conference creation and conference URI assignment > (It is possible to use SIP INVITE for this in ad hoc case,=20 > but something more permanent is definitely needed.) > - Authorization rules for joining the conference (~ACL) and=20 > doing some key operations, such as subscribing to conference=20 > state event. > - Doing mass-invitations/having a dial-out list. This should=20 > include mass-kickout functionality too. > (SIP exploders are supposed to do this too, so this may not=20 > belong to the most-important category if exploder solution=20 > turns out good, of course we should be thinking of non-SIP=20 > session management environments in XCON too.) > - Describing a small set of conference meta-data (Subject etc.) >=20 > At least I would be happy with a protocol that can initially=20 > do these operations. Timing/scheduling etc. could be added=20 > later. This makes an obvious requirement to the protocol that=20 > it must be extensible, and it should be possible to determine=20 > the feature set supported by the conference (policy) server. I believe timing is important and is one major advantage of CPCP over = ad-hoc conferences. What about security of the conference? is that a priority? How desides = on the level of security and what protocol to use? who sets the password = for the conference? I am ok with having a default authentication = mechanism like digest for joining a conference. There is also the issue of expelling users. What is the opinion on that? = Is it important? Regards, Hisham >=20 > Comments? Do people want to go along with all possible bells=20 > and whistles, or is there support for this descoping activity? >=20 > Markus =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 From exim@www1.ietf.org Sun Nov 30 14:19:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09259 for ; Sun, 30 Nov 2003 14:19:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQX5z-0000WD-3E for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 14:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUJJ32b001987 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 14:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQX5y-0000Vy-VL for xcon-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 14:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09246 for ; Sun, 30 Nov 2003 14:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQX5w-0003Lt-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 14:19:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQX5w-0003Lq-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 14:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQX5x-0000VV-EW; Sun, 30 Nov 2003 14:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQX5q-0000V9-0Y for xcon@optimus.ietf.org; Sun, 30 Nov 2003 14:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09234 for ; Sun, 30 Nov 2003 14:18:38 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQX5n-0003LL-00 for xcon@ietf.org; Sun, 30 Nov 2003 14:18:51 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AQX5m-0003LH-00 for xcon@ietf.org; Sun, 30 Nov 2003 14:18:50 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAUJIoY24817 for ; Sun, 30 Nov 2003 21:18:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 30 Nov 2003 21:18:50 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 30 Nov 2003 21:18:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 30 Nov 2003 21:18:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP - is XCAP suitable or not Date: Sun, 30 Nov 2003 21:18:49 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797452@esebe019.ntc.nokia.com> Thread-Topic: CPCP - is XCAP suitable or not Thread-Index: AcO3czIkCgBc+hYzRxWWUQcv3i78xQAAsK3Q To: , X-OriginalArrivalTime: 30 Nov 2003 19:18:49.0806 (UTC) FILETIME=[C8B86EE0:01C3B776] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't see a dial-out list as a non configuration thing for a = conference. It is logical to configure a conference with the participant = list that will be dialled out to just as well as a dial-in list. The = focus has to read the list and send INVITE requests to the members. = Adding members to a conference while the conference is in progress can = also be achieved. The moderator configures them into the dial-out list, = the focus learns of the changes to the dial-out list and generates = INVITE requests to the added users. Expelling users during the conference is an issue, but I think we solved = it quite well with XCAP. I prefer option a). I don't like the idea of developing 2 protocols that = are only usable if combined. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Markus.Isomaki@nokia.com > Sent: 30.November.2003 20:53 > To: xcon@ietf.org > Subject: [XCON] CPCP - is XCAP suitable or not >=20 >=20 > Hi, >=20 > There has been discussion on the mailing list and also in=20 > Minneapolis whether XCAP would be a good protocol to meet=20 > CPCP requirements or not. There is already a proposal showing=20 > how this could work by Hisham and Petri, but maybe there=20 > needs to be some more general discussion first. In the=20 > following I describe my understanding on the issues: >=20 > XCAP is designed for data manipulation, i.e. client can=20 > manipulate XML based information on a server. There is some=20 > limited intelligence included in the protocol via XML schema=20 > validation and computed data. XCAP is very suitable for=20 > operations which can be somehow modeled as configuration/data=20 > manipulation, i.e. manipulation some state on the server. It=20 > is less well suited for sending explicit commands to a server=20 > in a case where the client just wants the server to do some=20 > operation without creating more permanent state. XCAP as such=20 > lacks the abilty to convey events describing the state of=20 > what is going on in the requested operations (response to=20 > request needs to be sent according to HTTP rules), but to=20 > overcome that SIP could be used. >=20 > CPCP will presumably contain different types of=20 > operations/functionality. Conference creation and URI=20 > assigment seem equal to what is done with XCAP resource list=20 > AUID, so no problem there. Access and privilege rule=20 > management seems equal to what is done in XCAP presence=20 > authorization AUID, so that works too. Any parameter/metadata=20 > setting (subject, timing, ...) is also exactly what XCAP does.=20 >=20 > The main point of difficulty seems to be mass-invite/dial-out=20 > list and mass-kick-out functionality, since this seems more=20 > like commanding than configuring. It is however possible,=20 > even if not perhaps elegant, to model this as data=20 > manipulation as well, if we assume that the conference focus=20 > is an XCAP client too. It is possible to define that dial-out=20 > list is just another list which the client can manipulate,=20 > and the logic would be that if someone who is not currently=20 > in the conference is included to the list he is invited. Once=20 > the invitation attempt has been done (success or failure),=20 > the conference focus(?) may need to remove the entry from the=20 > list to prevent the list from growing eternally. SIP=20 > conference state event can be used by the client to monitor=20 > the progress of the attempt. Kick-outs could be done=20 > similarly by managing the access control. >=20 > At least I didn't come up with any other type of=20 > functionality that would be needed in CPCP. Based on this and=20 > the desire to reuse existing protocols (XCAP is probably=20 > included in many of the clients having CPCP in the future) I=20 > came up with two options that I would be happy with: > a) Do everything with XCAP by modeling the commands as data=20 > manipulation, probably as explained above with mass-invitation case > b) Do conf creation, parameter setting, ACL management with=20 > XCAP, and leave mass-invitations/kick-outs to some other=20 > protocol, which could be some very simple XML-RPC thing, or=20 > indeed, SIP exploder mechanism. >=20 > Obviously, there is option c) not to use XCAP at all, but I=20 > didn't come up with a compelling reason for that. >=20 > I believe that we just have to decide on which requirements=20 > to keep and how we proceed with the protocol (XCAP or=20 > something else) before the end of this year to have something=20 > ready at least somewhat close to the charter deadlines. >=20 > Markus >=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 exim@www1.ietf.org Sun Nov 30 14:28:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09879 for ; Sun, 30 Nov 2003 14:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQXEg-0001GO-9q for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 14:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUJS2W0004850 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 14:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQXEg-0001G9-4q for xcon-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 14:28:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09858 for ; Sun, 30 Nov 2003 14:27:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQXEd-0003gf-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 14:27:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQXEd-0003gb-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 14:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQXEf-0001Fa-2W; Sun, 30 Nov 2003 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQXEP-0001FD-JK for xcon@optimus.ietf.org; Sun, 30 Nov 2003 14:27:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09837 for ; Sun, 30 Nov 2003 14:27:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQXEM-0003fi-00 for xcon@ietf.org; Sun, 30 Nov 2003 14:27:42 -0500 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1AQXEL-0003fe-00 for xcon@ietf.org; Sun, 30 Nov 2003 14:27:41 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAUJRee9026461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Nov 2003 14:27:41 -0500 (EST) Message-ID: <3FCA44AC.1000305@cs.columbia.edu> Date: Sun, 30 Nov 2003 14:27:40 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Markus.Isomaki@nokia.com, xcon@ietf.org Subject: Re: [XCON] CPCP - making something simple that works References: <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B10F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I believe timing is important and is one major advantage of CPCP over > ad-hoc conferences. Note, however, that this can easily be done by an external application that uses a normal calendaring mechanism (such as the iCal extensions for events) and then generates CPCP requests. Having a very simple single start/end-time (no repeats) is sufficient for that and does not add significant complexity. > > What about security of the conference? is that a priority? How > desides on the level of security and what protocol to use? who sets > the password for the conference? I am ok with having a default > authentication mechanism like digest for joining a conference. I would find it peculiar if joining a conference required anything other than a standard SIP client, for example. > > There is also the issue of expelling users. What is the opinion on > that? Is it important? I have never seen that be used in real conferences, even where the feature was available. If this is a rather rare event, it is easier to create a new conference without the offending user and have everyone minus one move to the new conference. The much more common case is the executive session (or the jury session, e.g., for a thesis defense), which seems most readily modeled as two sessions with distinct participants, set up from the beginning. The problem with expelling is that this adds the risk of accidental invocation and probably does not deal with the full range of Robert's Rules stipulations and procedures. I think a natural threshold for initial inclusion is common usage in today's conferencing systems. Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Nov 30 16:50:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14019 for ; Sun, 30 Nov 2003 16:50:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZS7-0001qR-T3 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 16:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAULo3uf007087 for xcon-archive@odin.ietf.org; Sun, 30 Nov 2003 16:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZS7-0001qE-Oo for xcon-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 16:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14007 for ; Sun, 30 Nov 2003 16:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQZS5-00061y-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 16:50:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQZS5-00061v-00 for xcon-web-archive@ietf.org; Sun, 30 Nov 2003 16:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZS6-0001pu-7r; Sun, 30 Nov 2003 16:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQZRj-0001pE-1L for xcon@optimus.ietf.org; Sun, 30 Nov 2003 16:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13994 for ; Sun, 30 Nov 2003 16:49:23 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQZRg-00061f-00 for xcon@ietf.org; Sun, 30 Nov 2003 16:49:37 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQZRg-00061c-00 for xcon@ietf.org; Sun, 30 Nov 2003 16:49:36 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAULnZ817549 for ; Sun, 30 Nov 2003 23:49:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 30 Nov 2003 23:49:35 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 30 Nov 2003 23:49:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] CPCP - making something simple that works Date: Sun, 30 Nov 2003 23:49:34 +0200 Message-ID: Thread-Topic: [XCON] CPCP - making something simple that works Thread-Index: AcO3eAkKKdZjTvTQRZ2DS6KUfZNMVQAExULQ To: , Cc: X-OriginalArrivalTime: 30 Nov 2003 21:49:34.0964 (UTC) FILETIME=[D80E0340:01C3B78B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, There is one use scenario for CPCP where the capability to expell seems = necessary. I would like to build with SIP, MSRP and CPCP a "text = chatroom" service similar to something like what is available in IRC, = Jabber or Wireless Village. My understanding is that in those kind of = services expelling users is something which is actually used.=20 On the other hand, if you can do the same thing (for one participant at = a time) with SIP REFER, expelling may not be needed in the initial set = of CPCP features. Mass-expel is probably not used that much. Markus =20 > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 30 November, 2003 21:28 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Isomaki Markus (NRC/Helsinki); xcon@ietf.org > Subject: Re: [XCON] CPCP - making something simple that works >=20 >=20 >=20 > > I believe timing is important and is one major advantage of=20 > CPCP over > > ad-hoc conferences. >=20 > Note, however, that this can easily be done by an external=20 > application=20 > that uses a normal calendaring mechanism (such as the iCal extensions=20 > for events) and then generates CPCP requests. Having a very simple=20 > single start/end-time (no repeats) is sufficient for that and=20 > does not=20 > add significant complexity. >=20 > >=20 > > What about security of the conference? is that a priority? How > > desides on the level of security and what protocol to use? who sets > > the password for the conference? I am ok with having a default > > authentication mechanism like digest for joining a conference. >=20 > I would find it peculiar if joining a conference required=20 > anything other=20 > than a standard SIP client, for example. >=20 > >=20 > > There is also the issue of expelling users. What is the opinion on > > that? Is it important? >=20 > I have never seen that be used in real conferences, even where the=20 > feature was available. If this is a rather rare event, it is=20 > easier to=20 > create a new conference without the offending user and have everyone=20 > minus one move to the new conference. The much more common=20 > case is the=20 > executive session (or the jury session, e.g., for a thesis defense),=20 > which seems most readily modeled as two sessions with distinct=20 > participants, set up from the beginning. >=20 > The problem with expelling is that this adds the risk of accidental=20 > invocation and probably does not deal with the full range of Robert's=20 > Rules stipulations and procedures. >=20 > I think a natural threshold for initial inclusion is common usage in=20 > today's conferencing systems. >=20 > Henning >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon