From exim@www1.ietf.org Mon May 3 17:34:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03693 for ; Mon, 3 May 2004 17:34:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKklt-00055P-OV for xcon-archive@odin.ietf.org; Mon, 03 May 2004 17:14:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43LEfkc019551 for xcon-archive@odin.ietf.org; Mon, 3 May 2004 17:14:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKk1d-0004oK-3d for xcon-web-archive@optimus.ietf.org; Mon, 03 May 2004 16:26:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27351 for ; Mon, 3 May 2004 16:26:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKk1b-0001Wn-9A for xcon-web-archive@ietf.org; Mon, 03 May 2004 16:26:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKk0h-0001Qx-00 for xcon-web-archive@ietf.org; Mon, 03 May 2004 16:25:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKk0S-0001LI-00 for xcon-web-archive@ietf.org; Mon, 03 May 2004 16:25:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjak-0005wq-Nr; Mon, 03 May 2004 15:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjVt-0004lk-N0 for xcon@optimus.ietf.org; Mon, 03 May 2004 15:54:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25615; Mon, 3 May 2004 15:54:03 -0400 (EDT) Message-Id: <200405031954.PAA25615@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: xcon@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 03 May 2004 15:54:02 -0400 Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-xcap-00.txt 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : The Conference Policy Control Protocol (CPCP) Author(s) : H. Khartabil, P. Koskelainen Filename : draft-ietf-xcon-cpcp-xcap-00.txt Pages : 32 Date : 2004-5-3 This document describes the Conference Policy Control Protocol (CPCP). It specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy data elements that enable a user to define a conference policy. It also defines an XML Configuration Access Protocol (XCAP) application usage that is needed to store and manipulate a conference policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-xcap-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-cpcp-xcap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-cpcp-xcap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-3161407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-cpcp-xcap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-cpcp-xcap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-3161407.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 7 03:47:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03015 for ; Fri, 7 May 2004 03:47:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM01O-0002Qq-59 for xcon-archive@odin.ietf.org; Fri, 07 May 2004 03:43:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i477hoAE009348 for xcon-archive@odin.ietf.org; Fri, 7 May 2004 03:43:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLzsN-0007PW-8e for xcon-web-archive@optimus.ietf.org; Fri, 07 May 2004 03:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02355 for ; Fri, 7 May 2004 03:34:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLzsK-0001gs-V5 for xcon-web-archive@ietf.org; Fri, 07 May 2004 03:34:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLzrO-0001IR-00 for xcon-web-archive@ietf.org; Fri, 07 May 2004 03:33:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLzqe-0000tj-00 for xcon-web-archive@ietf.org; Fri, 07 May 2004 03:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLzn2-0005QG-N2; Fri, 07 May 2004 03:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLzgm-0003Wf-Ms for xcon@optimus.ietf.org; Fri, 07 May 2004 03:22:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01774 for ; Fri, 7 May 2004 03:22:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLzgk-0004Vu-FF for xcon@ietf.org; Fri, 07 May 2004 03:22:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLzfp-00046w-00 for xcon@ietf.org; Fri, 07 May 2004 03:21:34 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLzf4-0003Pv-00 for xcon@ietf.org; Fri, 07 May 2004 03:20:46 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i477K7Lc009423; Fri, 7 May 2004 02:20:08 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.125]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLAYSB; Fri, 7 May 2004 02:19:52 -0500 Message-ID: <409B38A8.9070503@ericsson.com> Date: Fri, 07 May 2004 10:20:08 +0300 X-Sybari-Trust: 315d91b6 08d63d2e 7e64d14e 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON , Joerg Ott , Keith Drage , Adam Roach , Alan Johnston Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Floor Control Draft 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we have just submitted the initial version of an I-D defining a floor control protocol. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt This is a preliminary version. We want to get your comments: is this approach OK overall? have we missed anything? etc. It would be great to start discussions on this topic as soon as possible, so that we can have an interesting session in Boston. We have installed an issue tracker to keep track of the open issues related to this draft. It is available at: http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/ Please, go through the open issues in the tracker before making your comments (we have introduced a bunch of them already). If your comments relate to an already open issue, reference it in your mail. This will make it easier to keep track of all your comments. Note that OMA needs a floor control protocol for its Push-To-Talk service. If people collaborate sending comments, we believe we can move this fast enough. Thanks, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 7 11:27:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01201 for ; Fri, 7 May 2004 11:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM76p-0001Qm-A1 for xcon-archive@odin.ietf.org; Fri, 07 May 2004 11:17:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47FHtfh005474 for xcon-archive@odin.ietf.org; Fri, 7 May 2004 11:17:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6kg-0000Lg-Af for xcon-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:55:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28785 for ; Fri, 7 May 2004 10:54:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6kd-0002Ka-RO for xcon-web-archive@ietf.org; Fri, 07 May 2004 10:54:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6jR-0001WV-00 for xcon-web-archive@ietf.org; Fri, 07 May 2004 10:53:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6hu-0000wn-00 for xcon-web-archive@ietf.org; Fri, 07 May 2004 10:52:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6a1-0004er-Bh; Fri, 07 May 2004 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5y7-0003E3-Tz for xcon@optimus.ietf.org; Fri, 07 May 2004 10:04:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22943 for ; Fri, 7 May 2004 10:04:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM5y5-000235-Q9 for xcon@ietf.org; Fri, 07 May 2004 10:04:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM5x9-0001d9-00 for xcon@ietf.org; Fri, 07 May 2004 10:03:52 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BM5we-0001Dc-00 for xcon@ietf.org; Fri, 07 May 2004 10:03:20 -0400 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 i47E3DDW017591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 May 2004 10:03:14 -0400 (EDT) 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 i47E3DgO009391; Fri, 7 May 2004 10:03:13 -0400 (EDT) Received: from localhost (xiaotaow@localhost) by disco.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id i47E38AT009388; Fri, 7 May 2004 10:03:08 -0400 (EDT) X-Authentication-Warning: disco.cs.columbia.edu: xiaotaow owned process doing -bs Date: Fri, 7 May 2004 10:03:07 -0400 (EDT) From: Xiaotao Wu To: Gonzalo Camarillo cc: XCON , Joerg Ott , Keith Drage , Adam Roach , Alan Johnston Subject: Re: [XCON] Floor Control Draft In-Reply-To: <409B38A8.9070503@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.6.100059 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='X_AUTH_WARNING 0, __TO_MALFORMED_2 0, __IN_REP_TO 0, __HAS_MSGID 0, __SANE_MSGID 0, __MIME_VERSION 0, __CT_TEXT_PLAIN 0, __CT 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, IN_REP_TO 0' 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In FloorRequest, should there be a parameter indicating privacy preference? The floor requester may request to talk anonymously so in FloorStatus, his name may be shown as 'Anonymous'. In FloorStatus, should there be some parameters indicating who is the floor chair, and how many people can hold the floor at the same time? Maybe a separate message should be used for this. Is that necessary to have a separate 'Ping' message for floor control? Should we just use the existing 'Ping' mechanisms, like the ping messages in session setup protocols. Thanks! -Xiaotao =========================================================== Name : Xiaotao Wu Email : xiaotaow@cs.columbia.edu 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 Fri, 7 May 2004, Gonzalo Camarillo wrote: > Folks, > > we have just submitted the initial version of an I-D defining a floor > control protocol. Until it appears in the archives, you can fetch it from: > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt > > This is a preliminary version. We want to get your comments: is this > approach OK overall? have we missed anything? etc. It would be great to > start discussions on this topic as soon as possible, so that we can have > an interesting session in Boston. > > We have installed an issue tracker to keep track of the open issues > related to this draft. It is available at: > > http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/ > > Please, go through the open issues in the tracker before making your > comments (we have introduced a bunch of them already). If your comments > relate to an already open issue, reference it in your mail. This will > make it easier to keep track of all your comments. > > Note that OMA needs a floor control protocol for its Push-To-Talk > service. If people collaborate sending comments, we believe we can move > this fast enough. > > Thanks, > > Gonzalo > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 7 12:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05030 for ; Fri, 7 May 2004 12:52:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8S6-0005Qq-15 for xcon-archive@odin.ietf.org; Fri, 07 May 2004 12:43:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Ghwtl020875 for xcon-archive@odin.ietf.org; Fri, 7 May 2004 12:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8OC-0004No-JL for xcon-web-archive@optimus.ietf.org; Fri, 07 May 2004 12:39:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04421 for ; Fri, 7 May 2004 12:39:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8OB-00022s-1z for xcon-web-archive@ietf.org; Fri, 07 May 2004 12:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8NM-0001be-00 for xcon-web-archive@ietf.org; Fri, 07 May 2004 12:39:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM8MR-00019q-00 for xcon-web-archive@ietf.org; Fri, 07 May 2004 12:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8Bg-00080H-F8; Fri, 07 May 2004 12:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM86q-0006Aj-1i for xcon@optimus.ietf.org; Fri, 07 May 2004 12:22:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03500 for ; Fri, 7 May 2004 12:21:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM86o-0001mh-IJ for xcon@ietf.org; Fri, 07 May 2004 12:21:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM85q-0001Gf-00 for xcon@ietf.org; Fri, 07 May 2004 12:20:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BM84s-0000OW-00 for xcon@ietf.org; Fri, 07 May 2004 12:19:58 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 May 2004 09:22:02 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47GJOYu013933; Fri, 7 May 2004 12:19:24 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF65375; Fri, 7 May 2004 12:19:23 -0400 (EDT) Message-ID: <409BB70B.4000304@cisco.com> Date: Fri, 07 May 2004 12:19:23 -0400 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: Gonzalo Camarillo CC: XCON , Joerg Ott , Keith Drage , Adam Roach , Alan Johnston Subject: Re: [XCON] Floor Control Draft References: <409B38A8.9070503@ericsson.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments at end. Thanks, Paul Gonzalo Camarillo wrote: > Folks, > > we have just submitted the initial version of an I-D defining a floor > control protocol. Until it appears in the archives, you can fetch it from: > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt > > > This is a preliminary version. We want to get your comments: is this > approach OK overall? have we missed anything? etc. It would be great to > start discussions on this topic as soon as possible, so that we can have > an interesting session in Boston. > > We have installed an issue tracker to keep track of the open issues > related to this draft. It is available at: > > http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/ > > Please, go through the open issues in the tracker before making your > comments (we have introduced a bunch of them already). If your comments > relate to an already open issue, reference it in your mail. This will > make it easier to keep track of all your comments. I did a quick read thru of draft-camarillo-xcon-bfcp-00, and I have a bunch of questions, some general, some detailed: The relationship between requests and responses is pretty loosely specified. I think that implicitly there are transactions, but this isn't clear. Does each client request have exactly one response? (I think not - I think any floor request can have multiple responses.) How does a client know when a request is done and can be forgotten? (Related to Issue 9) Are FloorStatus messages sent spontaneously by the server? There seems to be no way to request a FloorStatus message. This seems necessary for a client (especially a chair) to understand the state of the floors. Also, there seems to be no way to request a FloorRequestStatus. This is needed in order to fully interpret a FloorStatus message. (Related to issue 4, but more general - needed by non-chairs too.) How does the client learn his userid? Presumably this needs to be tied back to CPCP and/or the conference event package, or something in the dialog between a participant and the conference. In the Introduction the Userid is described as being 32 bits, but in the USER-ID attribute it is 16 bits. Which is it? RequestIds are supposed to be assigned by the client as random numbers. Is there any provision for what happens when the same value is reused? Do they only have to be unique for a single user, or over all users? If only for a single user, why do that have to be random? (Wouldn't it be sufficient to require them to be unique?) How does the client learn the valid floor numbers and their significance? (Need to know this in order to know what floor to request.) How does the client learn the significance of the different priority values? (They may be related to some particular rules of order.) All participants need to have a common understanding before priority can be used in a useful way. What does USER-URI identify about the user? Is it a sip AOR, a mailto uri, a contact address, or what? Can this field be used more than once to identify multiple features of the user? (Perhaps this should be the same as the User URI in CPCP.) How does the atomic method of handling multiple floor requests affect queuing? Can you be at the front of a queue and still have the floor granted to someone behind you because you're not at the head of the queue for some other floor? How does ChairAction work with floor requests for multiple floors? The chair request can only specify one floor when specifying the request to be acted upon. Does this break the atomicity? (Maybe ChairAction shouldn't mention a floor.) (Related to Issue 14) Using FloorReleaase to cancel a FloorRequest has a potential problem. It means that you can't request the floor (again) while you hold the floor. This is something that might be desired. (E.g. You hold the floor, but there is a queue behind you. You may want to enter the queue again for another subject before yielding the floor. (This can be fixed by having FloorRelease include the requestId of the request for the floor.) What happens if a client issues some requests that haven't yet been responded to, and then loses the connection? The client can reconnect, but the server won't know where to send the response. Does the server cancel the request if it can't send a response? It would be sad to be in queue for a long time and then lose that position because your connection dropped. (Related to Issue 5) Finally, I am curious why this binary protocol format was chosen over some other. (E.g. xml or some other text format.) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon May 10 06:50:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23574 for ; Mon, 10 May 2004 06:50:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8LT-0002AD-Fc for xcon-archive@odin.ietf.org; Mon, 10 May 2004 06:49:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AAnFmo008317 for xcon-archive@odin.ietf.org; Mon, 10 May 2004 06:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8G6-0001Bl-9n for xcon-web-archive@optimus.ietf.org; Mon, 10 May 2004 06:43:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23296 for ; Mon, 10 May 2004 06:43:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8G2-0002tI-9c for xcon-web-archive@ietf.org; Mon, 10 May 2004 06:43:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8F7-0002b7-00 for xcon-web-archive@ietf.org; Mon, 10 May 2004 06:42:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN8EZ-0002JI-00 for xcon-web-archive@ietf.org; Mon, 10 May 2004 06:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8DV-0000rT-1I; Mon, 10 May 2004 06:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8BC-0000fl-4a for xcon@optimus.ietf.org; Mon, 10 May 2004 06:38:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23141 for ; Mon, 10 May 2004 06:38:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8B7-0001Nm-S1 for xcon@ietf.org; Mon, 10 May 2004 06:38:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8A8-00015g-00 for xcon@ietf.org; Mon, 10 May 2004 06:37:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BN89P-0000og-00 for xcon@ietf.org; Mon, 10 May 2004 06:36:47 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4AAaWB01235; Mon, 10 May 2004 13:36:32 +0300 (EET DST) X-Scanned: Mon, 10 May 2004 13:36:22 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4AAaMpT014239; Mon, 10 May 2004 13:36:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Yl6l6g; Mon, 10 May 2004 13:36:14 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4AAaEH16595; Mon, 10 May 2004 13:36:14 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 May 2004 13:36:13 +0300 Message-ID: <409F5B1D.6040704@nokia.com> Date: Mon, 10 May 2004 13:36:13 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Gonzalo Camarillo CC: XCON , Joerg Ott , Keith Drage , Adam Roach , Alan Johnston Subject: Re: [XCON] Floor Control Draft References: <409B38A8.9070503@ericsson.com> In-Reply-To: <409B38A8.9070503@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2004 10:36:13.0331 (UTC) FILETIME=[9DB98E30:01C4367A] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: A few comments after my first browse through the document. - I would recommend to add a figure, in section 4, which gives a high-level overview of the packet format, e.g., containing the header and a bunch of attributes. - The ChairAction message is overwhelming me. This seems to be a kind of open message without clear semantics. The semantics are inside the message itself, if I understand correctly. Is it so that the "real" semantics of the message are in the Request-Status attribute? If that is correct, why not calling the message SetFloor or something similar. Who cares if the guy sending the message is a chair or not, it will be authenticated (I guess) at the server - Authentication mechanism: so is it so that the authentication mechanism is based on the knowledge of a shared secret, namely a user-token combination that serves as authentication? And you send it over TCP in the clear? It sounds a ver weak authentication mechanism. Perhaps it's worthy to investigate something more sofisticated based on hashes. - Most protocol specifications place mandatory attributes above optional ones. BFCP seems to fail in, e.g., FloorStatus, where the Request-Status attribute is located at the end. - Typo: ChairAction (section 5.5) seems to duplicate User-ID and Request-ID attributes. - Typo: Section 7.3 suddently speaks about SFTP. Regards, Miguel Gonzalo Camarillo wrote: > Folks, > > we have just submitted the initial version of an I-D defining a floor > control protocol. Until it appears in the archives, you can fetch it from: > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt > > > This is a preliminary version. We want to get your comments: is this > approach OK overall? have we missed anything? etc. It would be great to > start discussions on this topic as soon as possible, so that we can have > an interesting session in Boston. > > We have installed an issue tracker to keep track of the open issues > related to this draft. It is available at: > > http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/ > > Please, go through the open issues in the tracker before making your > comments (we have introduced a bunch of them already). If your comments > relate to an already open issue, reference it in your mail. This will > make it easier to keep track of all your comments. > > Note that OMA needs a floor control protocol for its Push-To-Talk > service. If people collaborate sending comments, we believe we can move > this fast enough. > > Thanks, > > Gonzalo > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon May 10 20:59:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19897 for ; Mon, 10 May 2004 20:59:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLVg-00010a-G6 for xcon-archive@odin.ietf.org; Mon, 10 May 2004 20:52:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B0qeYN003868 for xcon-archive@odin.ietf.org; Mon, 10 May 2004 20:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLPb-0008DR-Dj for xcon-web-archive@optimus.ietf.org; Mon, 10 May 2004 20:46:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19408 for ; Mon, 10 May 2004 20:46:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNLPZ-0004jt-2f for xcon-web-archive@ietf.org; Mon, 10 May 2004 20:46:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLOg-0004Od-00 for xcon-web-archive@ietf.org; Mon, 10 May 2004 20:45:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNLNi-000439-00 for xcon-web-archive@ietf.org; Mon, 10 May 2004 20:44:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLEf-00067C-Hm; Mon, 10 May 2004 20:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLBx-0005JM-DS for xcon@optimus.ietf.org; Mon, 10 May 2004 20:32:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18691 for ; Mon, 10 May 2004 20:32:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNLBv-0007ks-35 for xcon@ietf.org; Mon, 10 May 2004 20:32:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLB2-0007R3-00 for xcon@ietf.org; Mon, 10 May 2004 20:31:21 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1BNLAN-000720-00 for xcon@ietf.org; Mon, 10 May 2004 20:30:39 -0400 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 i4B0TrbP009869; Mon, 10 May 2004 19:29:53 -0500 (CDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 May 2004 19:29:53 -0500 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A51B@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Gonzalo Camarillo Cc: XCON , Joerg Ott , Keith Drage , Adam Roach , Alan Johnston Subject: RE: [XCON] Floor Control Draft Date: Mon, 10 May 2004 19:29:51 -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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 [as a participant] Paul Kyzivat [mailto:pkyzivat@cisco.com] wrote: > Finally, I am curious why this binary protocol format was chosen over > some other. (E.g. xml or some other text format.) This choice was made to satisfy the requirements. We just last called them, so I'm going to assume you just overlooked this on your recent thorough scrub of the document: REQ-17: Bandwidth and terminal limitations SHOULD be taken into account in order to ensure that floor control can be efficiently used in mobile environments. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue May 11 03:24:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07986 for ; Tue, 11 May 2004 03:24:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRPw-0000KV-Kx for xcon-archive@odin.ietf.org; Tue, 11 May 2004 03:11:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B7B8ni001263 for xcon-archive@odin.ietf.org; Tue, 11 May 2004 03:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRAR-0005A5-I4 for xcon-web-archive@optimus.ietf.org; Tue, 11 May 2004 02:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06925 for ; Tue, 11 May 2004 02:55:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNRAN-0002e9-Na for xcon-web-archive@ietf.org; Tue, 11 May 2004 02:55:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNR9P-0002DR-00 for xcon-web-archive@ietf.org; Tue, 11 May 2004 02:54:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNR8A-0001k2-00 for xcon-web-archive@ietf.org; Tue, 11 May 2004 02:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNQwG-0001ks-Uh; Tue, 11 May 2004 02:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNQrW-0000XK-Iq for xcon@optimus.ietf.org; Tue, 11 May 2004 02:35:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05894 for ; Tue, 11 May 2004 02:35:31 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNQrS-0003Bm-UD for xcon@ietf.org; Tue, 11 May 2004 02:35:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNQqY-0002ql-00 for xcon@ietf.org; Tue, 11 May 2004 02:34:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BNQqE-0002Vd-00 for xcon@ietf.org; Tue, 11 May 2004 02:34:14 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B6YEB24052 for ; Tue, 11 May 2004 09:34:14 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 09:34:09 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4B6Y9hb021581 for ; Tue, 11 May 2004 09:34:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 008o0PAx; Tue, 11 May 2004 09:34:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B6Y2H18406 for ; Tue, 11 May 2004 09:34:02 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 09:33:59 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 09:33:59 +0300 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: Tue, 11 May 2004 09:33:58 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A95@esebe019.ntc.nokia.com> Thread-Topic: Deadline for internet drafts submission before interim Thread-Index: AcQ3IfD3WftxnU3iTAKusG27GNBzoA== To: X-OriginalArrivalTime: 11 May 2004 06:33:59.0472 (UTC) FILETIME=[F1486B00:01C43721] Content-Transfer-Encoding: quoted-printable Subject: [XCON] Deadline for internet drafts submission before interim 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The Deadline for submitting internet drafts for discussion at the = interim meeting is Monday 17th May. This hopefully gives attendees = enough time to read the IDs to enable them to engage in discussions. Regards, Hisham (on behalf of the SIMPLE, SIP, SIPPING and XCON WG chairs) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue May 11 05:59:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15695 for ; Tue, 11 May 2004 05:59:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNU1A-0005WS-QC for xcon-archive@odin.ietf.org; Tue, 11 May 2004 05:57:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B9viKQ021228 for xcon-archive@odin.ietf.org; Tue, 11 May 2004 05:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTpL-0003lu-GR for xcon-web-archive@optimus.ietf.org; Tue, 11 May 2004 05:45:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15150 for ; Tue, 11 May 2004 05:45:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNTpI-0003Nf-4R for xcon-web-archive@ietf.org; Tue, 11 May 2004 05:45:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNTnJ-0002nB-00 for xcon-web-archive@ietf.org; Tue, 11 May 2004 05:43:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNTlG-000247-00 for xcon-web-archive@ietf.org; Tue, 11 May 2004 05:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTWW-0008OI-I7; Tue, 11 May 2004 05:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTTE-0007o0-Hs for xcon@optimus.ietf.org; Tue, 11 May 2004 05:22:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14194 for ; Tue, 11 May 2004 05:22:37 -0400 (EDT) From: petri.koskelainen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNTTB-0003XA-7p for xcon@ietf.org; Tue, 11 May 2004 05:22:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNTSA-000394-00 for xcon@ietf.org; Tue, 11 May 2004 05:21:34 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BNTR7-0002bC-00 for xcon@ietf.org; Tue, 11 May 2004 05:20:29 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B9KLH06415; Tue, 11 May 2004 12:20:21 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 12:20:12 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4B9KC0T015582; Tue, 11 May 2004 12:20:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Tpci80; Tue, 11 May 2004 12:20:10 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B9K0H21145; Tue, 11 May 2004 12:20:00 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 12:19:56 +0300 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 12:19:56 +0300 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: Tue, 11 May 2004 12:19:55 +0300 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E9BD93@trebe004.europe.nokia.com> Thread-Topic: Floor control requirements: WGLC summary Thread-Index: AcQ3OR9FpbBwXg9ARoK4eC+fcmnP3A== To: , Cc: X-OriginalArrivalTime: 11 May 2004 09:19:56.0139 (UTC) FILETIME=[1FEB3BB0:01C43739] Content-Transfer-Encoding: quoted-printable Subject: [XCON] Floor control requirements: WGLC summary 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The WG Last Call for floor control requirements document=20 ( = http://www.ietf.org/internet-drafts/draft-ietf-xcon-floor-control-req-00.= txt ) has passed. Here is the list of main issues raised during the LC. If you feel something important is missing please comment asap. Security/Privacy issues This needs further clarification in the document. Our=20 proposal is to adopt general protocol requirements from CPCP-reqs=20 section 6.9 (with only minor modifications). Additional privacy related requirement is also needed, as follows: REQ-X: It MUST be possible for a floor claimer to request=20 privacy both for the identity of floor claimer and floor holding. Note: The moderator still learns the=20 identity unless user has joined anonymously. One issue to be solved is who can see the floor chair=20 identitity (e.g. whether it is hidden, known by some subset of=20 users or by all users). Our proposed solution is that when floor is created (via CPCP etc) the creator defines=20 floor chair identity as hidden/public. There were also a lot of editorial comments, such as=20 regrouping requirements, moving CPCP-related requirements to=20 separate section etc. Next version (to be submitted shortly) will cover these changes. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue May 11 18:06:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00548 for ; Tue, 11 May 2004 18:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfHx-0004oR-Dl for xcon-archive@odin.ietf.org; Tue, 11 May 2004 17:59:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BLxnXN018499 for xcon-archive@odin.ietf.org; Tue, 11 May 2004 17:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNexy-0007Uj-4B for xcon-web-archive@optimus.ietf.org; Tue, 11 May 2004 17:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27842 for ; Tue, 11 May 2004 17:39:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNexv-0004M9-GD for xcon-web-archive@ietf.org; Tue, 11 May 2004 17:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNewR-0003f4-00 for xcon-web-archive@ietf.org; Tue, 11 May 2004 17:37:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNevW-0003Bt-01 for xcon-web-archive@ietf.org; Tue, 11 May 2004 17:36:39 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BNeqR-0005jr-EP for xcon-web-archive@ietf.org; Tue, 11 May 2004 17:31:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNePx-00042F-Pd; Tue, 11 May 2004 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeAf-0000po-1H for xcon@optimus.ietf.org; Tue, 11 May 2004 16:48:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24437 for ; Tue, 11 May 2004 16:48:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeAc-0005cd-Vz for xcon@ietf.org; Tue, 11 May 2004 16:48:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNe9j-0005Cl-00 for xcon@ietf.org; Tue, 11 May 2004 16:47:16 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1BNe8n-0004Nn-00 for xcon@ietf.org; Tue, 11 May 2004 16:46:17 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HXK00CLSHOBIX@firewall.mci.com> for xcon@ietf.org; Tue, 11 May 2004 20:45:48 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HXK00K01HKCJR@pmismtp01.mcilink.com>; Tue, 11 May 2004 20:45:47 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.152.222]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HXK00KE8HNP56@pmismtp01.mcilink.com>; Tue, 11 May 2004 20:45:27 +0000 (GMT) Date: Tue, 11 May 2004 15:45:24 -0500 From: Alan Johnston Subject: Re: [XCON] Authorization in conference policy In-reply-to: <408F997D.9050404@nokia.com> X-Sender: Alan.Johnston@pop.mcilink.com To: Aki Niemi , XCON WG Cc: Henning Schulzrinne , Jonathan Rosenberg , jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, Ted Hardie , "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" , "Koskelainen Petri (Nokia-NRC/Tampere)" Message-id: <5.2.1.1.0.20040511153947.03a708d0@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Aki, Thanks for bringing this up. I do think it would be worthwhile to do a comparison of presence and location policy and the conference policy that we are developing in XCON. If there are major differences or divergences, it would be good to know what they are (such as the all-except construct you mention below). Having said that, I'm not so certain that conference policy needs to formally be aligned with the common policy framework, as the differences between it and the other policies seem to be greater than the similarities. However, if there are some concrete advantages to doing so, I think the working group should consider this approach. Thanks, Alan Johnston co-chair XCON At 02:46 PM 4/28/2004 +0300, Aki Niemi wrote: >Hi All, > >Currently, XCAP-CPCP [1] includes the definition of data elements for >implementing authorization rules and permission rules (privileges) for >conferences. Along with the definition of those elements, it defines its >own rule syntax. > >Common-policy [2] defines an authorization policy framework, intended >for use in different applications to control access to data. It includes >a syntax for common policy rules that are currently being used to >describe authorization policies in location and SIP presence >applications. Also, the common policy framework can be extended to >accomodate other application needs. > >In short, this framework defines policy as a set of rules where the >respective ordering of rules does not matter. Each rule consists of a >condition for matching some property (e.g., identity of the requestor of >data); and permissions that are to be applied in case the "condition" >part has evaluated to true. > >It seems natural that the conference policy work would also benefit from >adopting the common-policy framework. > >However, one of the intended usages of conference policy is to control >the participation to a conference. To expel a participant from an >ongoing conference, the conference policy would be manipulated in such a >way that the participant is no longer allowed to participate, effecting >a removal of that participant from the conference. The need for >expelling users is also independent of the original admittance policy. >Even in conferences that have open admittance (i.e. anyone can join), a >moderator would need to be able to expel users who are disturbing the >conference, e.g., expel a participant from a chat room for using >explicit language. > >In common-policy point of view, the above would require an "all-except" >construct, which I believe currently is not allowed in common-policy. >Question is, can this be worked around, if we were to adopt >common-policy in the conference policy work? > >And if yes, would XCON be willing to see common-policy adopted in the >conference policy work? > >The advantages would include having a unified syntax for policy rules in >these different applications, including a clear extension model etc. > >Disadvantages (pending the resolution of the above issue) would be >having to rewrite the authorization policy parts of XCAP-CPCP, causing a >delay. > >Thoughts? > >Cheers, >Aki > >[1] >http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xcap-cpcp-usage-02.txt > >[2] >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt > > >_______________________________________________ >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 May 12 01:22:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21807 for ; Wed, 12 May 2004 01:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNm9y-0007F8-4w for xcon-archive@odin.ietf.org; Wed, 12 May 2004 01:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C5K1LP027820 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 01:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNm1m-00055i-1J for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 01:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21082 for ; Wed, 12 May 2004 01:11:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNm1j-0000g8-3x for xcon-web-archive@ietf.org; Wed, 12 May 2004 01:11:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNm0p-0000G2-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 01:10:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNlzw-0007dC-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 01:09:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlog-0002DD-9E; Wed, 12 May 2004 00:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlgV-0000Y8-BO for xcon@optimus.ietf.org; Wed, 12 May 2004 00:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20252 for ; Wed, 12 May 2004 00:49:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNlgS-0006i9-KY for xcon@ietf.org; Wed, 12 May 2004 00:49:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlfO-0006Gj-00 for xcon@ietf.org; Wed, 12 May 2004 00:48:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNleQ-0005QF-00 for xcon@ietf.org; Wed, 12 May 2004 00:47:26 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C4lBus029346; Wed, 12 May 2004 00:47:11 -0400 (EDT) Message-ID: <40A1AC2F.9090309@dynamicsoft.com> Date: Wed, 12 May 2004 00:46:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: XCON , Joerg Ott , Keith Drage , Adam Roach , Alan Johnston Subject: Re: [XCON] Floor Control Draft References: <409B38A8.9070503@ericsson.com> In-Reply-To: <409B38A8.9070503@ericsson.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some general comments: * Its not clear to me that there is really a need for a BFCP URI. BFCP doesn't make sense as a stanalone protocol, it needs to be set up by something else. So, just like there is no RTP URI, I dont see a need for a BFCP URI * is there a reason for allowing multiple transports for this protocol? I think this has introduced a lot of complexity into sip, and in hindsight, I think it is far more beneficial to pick one. Its not obvious whether it should be UDP or TCP. If we think that we'll have centralized servers for this (that are publically addressable), tcp is probably better. But, if we think floor control will often run peer to peer (that is, the floor control server is colocated with an endpoint), UDP might be easier from a nat perspective, since you could avoid relays. * handling of the TOKEN parameter was really unlear. Generally, the security features in bfcp are not clear and need to be worked. I'd recommend taking a look at stun, which is a good example of how to provide authentication and integrity based on an out-of-band shared secret in a TLV protocol. * I agree with Paul that the meaning of the various IDs is unclear. I'd suggest separating out transaction IDs (request/response) from other types of identifiers. Again, another mistake we made in rfc2543 that was corrected in 3261. * A major issue we need to work is how the various parameters that are needed here (the userid, conferenceid, floorid, token) are determined from the conferencing framework. Are these signaled in SIP/SDP? THrough CPCP? Do we assume that the focus and floor control server are colocated? If not, seems like some kind of connection is required. Thanks, Jonathan R. Gonzalo Camarillo wrote: > Folks, > > we have just submitted the initial version of an I-D defining a floor > control protocol. Until it appears in the archives, you can fetch it from: > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt > > > This is a preliminary version. We want to get your comments: is this > approach OK overall? have we missed anything? etc. It would be great to > start discussions on this topic as soon as possible, so that we can have > an interesting session in Boston. > > We have installed an issue tracker to keep track of the open issues > related to this draft. It is available at: > > http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/ > > Please, go through the open issues in the tracker before making your > comments (we have introduced a bunch of them already). If your comments > relate to an already open issue, reference it in your mail. This will > make it easier to keep track of all your comments. > > Note that OMA needs a floor control protocol for its Push-To-Talk > service. If people collaborate sending comments, we believe we can move > this fast enough. > > Thanks, > > Gonzalo > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 12:57:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26289 for ; Wed, 12 May 2004 12:57:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwre-0005So-Vi for xcon-archive@odin.ietf.org; Wed, 12 May 2004 12:45:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CGjosF021002 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 12:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwhT-0000p7-1z for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 12:35:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24165 for ; Wed, 12 May 2004 12:35:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwhR-0007CS-Eh for xcon-web-archive@ietf.org; Wed, 12 May 2004 12:35:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNweH-00064c-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 12:32:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNwcI-0004TI-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 12:29:59 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BNwF8-00047a-AY for xcon-web-archive@ietf.org; Wed, 12 May 2004 12:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvYZ-0007s3-BQ; Wed, 12 May 2004 11:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvBc-0005pO-0N for xcon@optimus.ietf.org; Wed, 12 May 2004 10:58:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13458 for ; Wed, 12 May 2004 10:58:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNvBZ-0002RG-Dn for xcon@ietf.org; Wed, 12 May 2004 10:58:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNv9X-0001Dq-00 for xcon@ietf.org; Wed, 12 May 2004 10:56:12 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BNv6h-0007a5-00 for xcon@ietf.org; Wed, 12 May 2004 10:53:15 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HXL009GZVZWIC@firewall.mci.com> for xcon@ietf.org; Wed, 12 May 2004 14:52:44 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HXL00G01VV5GI@pmismtp02.mcilink.com>; Wed, 12 May 2004 14:52:44 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.113.142]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HXL00FF5VZKW3@pmismtp02.mcilink.com>; Wed, 12 May 2004 14:52:33 +0000 (GMT) Date: Wed, 12 May 2004 09:52:29 -0500 From: Alan Johnston Subject: Re: [XCON] Floor Control Draft In-reply-to: <40A1AC2F.9090309@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcilink.com To: Jonathan Rosenberg , Gonzalo Camarillo Cc: XCON , Joerg Ott , Keith Drage , Adam Roach Message-id: <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <409B38A8.9070503@ericsson.com> <409B38A8.9070503@ericsson.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Jonathan, Thanks for raising these good points. See my comments below. Thanks Alan Johnston (not as chair) At 12:46 AM 5/12/2004 -0400, Jonathan Rosenberg wrote: >Some general comments: > >* Its not clear to me that there is really a need for a BFCP URI. BFCP >doesn't make sense as a stanalone protocol, it needs to be set up by >something else. So, just like there is no RTP URI, I dont see a need for a >BFCP URI We need offer/answer and SDP for RTP because there are so many parameters to negotiate - IP address, port number, codec, bit rate, etc. I don't see any such negotiation for floor control. I really hope that the floor control protocol is simple enough that just passing a URI is sufficient for a client to set up the session. I'm interested in others view of the use of SDP. This was the approach discussed in http://www.softarmor.com/wgdb/docs/draft-wu-sipping-floor-control-03.txt and should be considered. >* is there a reason for allowing multiple transports for this protocol? I >think this has introduced a lot of complexity into sip, and in hindsight, >I think it is far more beneficial to pick one. Its not obvious whether it >should be UDP or TCP. If we think that we'll have centralized servers for >this (that are publically addressable), tcp is probably better. But, if we >think floor control will often run peer to peer (that is, the floor >control server is colocated with an endpoint), UDP might be easier from a >nat perspective, since you could avoid relays. I am also not comfortable with multiple transport protocols - this seems more complex than necessary. I'm interested in the peer-to-peer uses of floor control you mention. Currently they are not described in our scenarios document or in the floor control requirements - can you give some examples? >* handling of the TOKEN parameter was really unlear. Generally, the >security features in bfcp are not clear and need to be worked. I'd >recommend taking a look at stun, which is a good example of how to provide >authentication and integrity based on an out-of-band shared secret in a >TLV protocol. > >* I agree with Paul that the meaning of the various IDs is unclear. I'd >suggest separating out transaction IDs (request/response) from other types >of identifiers. Again, another mistake we made in rfc2543 that was >corrected in 3261. > >* A major issue we need to work is how the various parameters that are >needed here (the userid, conferenceid, floorid, token) are determined from >the conferencing framework. Are these signaled in SIP/SDP? THrough CPCP? I would prefer CPCP or the conference package but I'm interested in others opinions. This is an important issue to get resolved. >Do we assume that the focus and floor control server are colocated? If >not, seems like some kind of connection is required. The decomposition of a conference service and any protocols needed between the elements are not in scope for XCON. >Thanks, >Jonathan R. > >Gonzalo Camarillo wrote: > >>Folks, >>we have just submitted the initial version of an I-D defining a floor >>control protocol. Until it appears in the archives, you can fetch it from: >>http://standards.ericsson.net/gonzalo/papers/draft-camarillo-xcon-bfcp-00.txt >> >>This is a preliminary version. We want to get your comments: is this >>approach OK overall? have we missed anything? etc. It would be great to >>start discussions on this topic as soon as possible, so that we can have >>an interesting session in Boston. >>We have installed an issue tracker to keep track of the open issues >>related to this draft. It is available at: >>http://s99.piuha.net/cgi-bin/roundup.cgi/floor-control/ >>Please, go through the open issues in the tracker before making your >>comments (we have introduced a bunch of them already). If your comments >>relate to an already open issue, reference it in your mail. This will >>make it easier to keep track of all your comments. >>Note that OMA needs a floor control protocol for its Push-To-Talk >>service. If people collaborate sending comments, we believe we can move >>this fast enough. >>Thanks, >>Gonzalo >> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 15:59:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07523 for ; Wed, 12 May 2004 15:59:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzmf-00081q-P0 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 15:52:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CJqrLi030857 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 15:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzjm-0006lR-DB for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:49:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06817 for ; Wed, 12 May 2004 15:49:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzjk-00059l-SJ for xcon-web-archive@ietf.org; Wed, 12 May 2004 15:49:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzip-0004e1-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 15:48:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzhq-00045f-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 15:47:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzZH-00048V-Jb; Wed, 12 May 2004 15:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzUU-0002Fz-RJ for xcon@optimus.ietf.org; Wed, 12 May 2004 15:34:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05805 for ; Wed, 12 May 2004 15:34:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzUS-0004Ti-Ee for xcon@ietf.org; Wed, 12 May 2004 15:34:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzTT-0003xo-00 for xcon@ietf.org; Wed, 12 May 2004 15:33:04 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BNzSj-0003RV-00 for xcon@ietf.org; Wed, 12 May 2004 15:32:17 -0400 Received: from unknown (HELO DBSTNR11) (cjbennett@sbcglobal.net@67.115.8.199 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 12 May 2004 18:45:46 -0000 Message-ID: <002501c43851$4c81add0$2f90fea9@DBSTNR11> From: "Chris Bennett" To: Subject: Re: [XCON] Floor Control Draft Date: Wed, 12 May 2004 11:45:29 -0700 Organization: Vista Systems MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C43816.9FC41400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C43816.9FC41400 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all -- I am with Togabi Technologies. We are a startup working on Push to Talk = over Cellular. We have been involved in the OMA PoC work for a while = now, and I have also been monitoring the XCON mailing list. Since we = have a particular interest in floor control for PoC, I thought it might = be worth offering a few general comments on the draft XCON BFCP from a = PoC- and OMA-oriented viewpoint. In Togabi's view, the key issue is to make PoC work as effectively as = possible over a very narrowband channel. On CDMA networks, we are = looking at a 9.6 kbps fundamental channel. In GPRS the constraint is a = single timeslot with CS1 encoding -- 8 kbps. This has to cover all = media and all overhead, down to the MAC layer. Further, while network = enhancements like ROHC are coming down the pipe quite fast, there is = strong pressure to get a PoC standard finalised this year with = deployment as soon as possible thereafter. This pressure includes = interest from customers who are looking only to deploy a PoC = application, and may not upgrade their networks for some time. So, the = FCP solution needs to work well in a very constrained environment, = meaning that overhead costs which may be tolerable in other environments = have to eliminated if possible. From this perspective, a text-based FCP is a nonstarter for OMA, = whatever value it may have elsewhere. Fielded proprietary PoC systems = which used SIP INFO to deliver floor control have had to rework their = FCP because of the performance inefficiencies involved. While I think = Togabi's views on nearterm performance efficiency are not universally = shared in OMA, I'm sure you would find general agreement there that a = binary approach is required. =20 As in XCON, there is a debate in OMA as to what should be used as the = transport protocol for an FCP. The main camps are not UDP vs TCP, = however, but RTCP (via APP packets) vs RTP (via Extended Header). Both = camps assume RT(C)P over UDP. =20 It's hard for me to put the argument for the RTCP position since, = frankly, I don't understand what advantages it offers over a straight = UDP (or TCP) transport, as in the proposed XCON BFCP. The proposal is = coupled with a proposal to suspend RTCP's compounding and periodic = transmission requirements for these APP packets, so that you use them = transactionally, and if you do this I don't think you have RTCP any = more. Hopefully a proponent monitoring this list can step in to present = a more positive picture. This proposal has a lot of support in OMA. It = is backed by a number of companies who have brought in a "consortium = specification" to OMA, and allied carriers. It may well prevail for = this reason if no other. The RTP position has mostly actively been championed by ourselves, = although it has had some support from other companies such as Nortel and = Huawei, and has some outside academic support -- see = http://research.ac.upc.es/EW2004/papers/144.pdf . Our argument is that = there are some FCP transactions which interact with the media, notably = those that signal new speakers, end of talk bursts, and, most = importantly, queue status updates, if the FCP supports queued requests = (which is optional in OMA). The first two require synchronisation with = media. The last doesn't, but will typically be sent concurrently with = PoC media and in the same direction, so can induce jitter across the = radio link. By using RTP Extended Headers, it is possible to tunnel = these FCP messages through the media channel, eliminating the = lower-layer overhead for these messages. Whether OMA deems this effect = significant enough on narrowband channels to be useful remains to be = seen. [Since the point has come up in OMA, it is perhaps worth saying here = that use of an RTP-based format doesn't mean that FCP must use the same = ports as an RTP media stream, only that it becomes possible to do so = when advantageous.] =20 As for Gonzalo's draft, my reaction is that its a good start. Its clear = from other comments that a lot of clarification is needed on details and = I don;t really have much to add to those. There are certainly aspects = of it -- such as ChairAction -- which look rather complex and are simply = not needed for the OMA application. In Togabi's own work on FCP, we = came up with a kind of micro-TLV+BER syntax to allow for expansion of = parameters to arbitrary lengths while keeping it very compact for the = usual case, but this type of optimisation is only of value on very = narrow channels, and only when the FCP body is of the order of the = transmission overhead, so its not clear to me its of interest to XCON. I would say, though, that if XCON would like OMA to adopt an XCON BFCP = for PoC, it will have to move fast. The OMA FCP signalling flows and = choice of bearer protocol are scheduled to be settled the week after = next, and the target is to have OMA PoC stahdards ready by year end. Regards, Chris Bennett ------=_NextPart_000_0022_01C43816.9FC41400 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all --
 
I am with Togabi Technologies.  We = are a=20 startup working on Push to Talk over Cellular.  We have been = involved in=20 the OMA PoC work for a while now, and I have also been monitoring the = XCON=20 mailing list.  Since we have a particular interest in = floor control=20 for PoC, I thought it might be worth offering a few general comments on = the=20 draft XCON BFCP from a PoC- and OMA-oriented = viewpoint.
 
In Togabi's view, the key issue is to = make PoC work=20 as effectively as possible over a very narrowband = channel.   On=20 CDMA networks, we are looking at a 9.6 kbps fundamental = channel.  In=20 GPRS the constraint is a single timeslot with CS1 encoding -- 8 = kbps. =20 This has to cover all media and all overhead, down to the MAC = layer. =20 Further, while network enhancements like ROHC are coming down the pipe = quite=20 fast, there is strong pressure to get a PoC standard finalised this year = with=20 deployment as soon as possible thereafter.  This pressure includes = interest=20 from customers who are looking only to deploy a PoC application, and may = not=20 upgrade their networks for some time.  So, the FCP solution needs = to work=20 well in a very constrained environment, meaning that overhead costs = which may be=20 tolerable in other environments have to eliminated if = possible.
 
From this perspective, a = text-based FCP is a=20 nonstarter for OMA, whatever value it may have = elsewhere.  Fielded=20 proprietary PoC systems which used SIP INFO to deliver floor control = have had to=20 rework  their FCP because of the performance inefficiencies = involved. =20 While I think Togabi's views on nearterm performance efficiency are = not=20 universally shared in OMA, I'm sure you would find general agreement = there that=20 a binary approach is required. 
 
As in XCON, there is a debate in OMA as = to what=20 should be used as the transport protocol for an FCP.  The main = camps are=20 not UDP vs TCP, however, but RTCP (via APP packets) vs RTP (via Extended = Header).  Both camps assume RT(C)P over UDP. 
 
It's hard for me to put the argument = for the RTCP=20 position since, frankly, I don't understand what advantages it offers = over a=20 straight UDP (or TCP) transport, as in the proposed XCON BFCP.  The = proposal is coupled with a proposal to suspend RTCP's = compounding and=20 periodic transmission requirements for these APP packets, so that you = use them=20 transactionally, and if you do this I don't think you have RTCP any = more. =20 Hopefully a proponent monitoring this list can step in to present a more = positive picture.  This proposal has a lot of support in OMA.  = It is=20 backed by a number of companies who have brought in a "consortium=20 specification" to OMA, and allied carriers.  It may well = prevail for=20 this reason if no other.
 
The RTP position has mostly actively been = championed by=20 ourselves, although it has had some support from other companies such as = Nortel=20 and Huawei, and has some outside academic support -- see http://research.ac.upc.es/EW2004/papers/144.pdf .  Our argument is that there are some = FCP=20 transactions which interact with the media, notably those that = signal new=20 speakers, end of talk bursts, and, most importantly, queue status = updates, if=20 the FCP supports queued requests (which is optional in OMA).  The = first two=20 require synchronisation with media.  The last doesn't, but will = typically=20 be sent concurrently with PoC media and in the same direction, so can=20 induce jitter across the radio link.  By using RTP Extended = Headers,=20 it is possible to tunnel these FCP messages through the media channel,=20 eliminating the lower-layer overhead for these messages.  Whether = OMA deems=20 this effect significant enough on narrowband channels to be useful = remains to be=20 seen.
 
[Since the point has come up in OMA, it is perhaps = worth=20 saying here that use of an RTP-based format doesn't mean that FCP must = use the=20 same ports as an RTP media stream, only that it becomes possible to do = so when=20 advantageous.]    
 
As for Gonzalo's draft, my reaction is = that its a=20 good start.  Its clear from other comments that a lot of = clarification=20 is needed on details and I don;t really have much to add to those.  = There are certainly aspects of it -- = such as=20 ChairAction -- which look rather complex and are simply not needed for = the OMA=20 application.  In Togabi's own work on FCP, we came up with a kind = of=20 micro-TLV+BER syntax to allow for expansion of parameters to = arbitrary=20 lengths while keeping it very compact for the usual case, but this type = of=20 optimisation is only of value on very narrow channels, and=20 only when the FCP body is of the order of the transmission = overhead,=20 so its not clear to me its of interest to XCON.
 
I would say, though, that if XCON would = like OMA to=20 adopt an XCON BFCP for PoC, it will have to move fast.  The = OMA FCP=20 signalling flows and choice of bearer protocol are scheduled to be = settled the=20 week after next, and the target is to have OMA PoC stahdards ready by = year=20 end.
 
Regards,
Chris Bennett
 
 

------=_NextPart_000_0022_01C43816.9FC41400-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 16:10:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08143 for ; Wed, 12 May 2004 16:10:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzyD-0002wE-0l for xcon-archive@odin.ietf.org; Wed, 12 May 2004 16:04:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CK4mQY011289 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 16:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNztW-0001TZ-RD for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07592 for ; Wed, 12 May 2004 15:59:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNztV-0002mD-B7 for xcon-web-archive@ietf.org; Wed, 12 May 2004 15:59:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzse-0002Fv-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 15:59:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzrf-0001in-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 15:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzlr-0007dO-I1; Wed, 12 May 2004 15:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzcB-000503-VI for xcon@optimus.ietf.org; Wed, 12 May 2004 15:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02890 for ; Wed, 12 May 2004 14:54:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNysK-0000L5-0J for xcon@ietf.org; Wed, 12 May 2004 14:54:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNyrW-0007eV-00 for xcon@ietf.org; Wed, 12 May 2004 14:53:51 -0400 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1BNyql-00071i-00 for xcon@ietf.org; Wed, 12 May 2004 14:53:03 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i4CInq8f004677; Wed, 12 May 2004 13:49:52 -0500 (CDT) Message-ID: <40A271C9.7080505@alcatel.com> Date: Wed, 12 May 2004 13:49:45 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: Aki Niemi , XCON WG , Henning Schulzrinne , Jonathan Rosenberg , jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, Ted Hardie , "Khartabil Hisham (Nokia-TP-MSW/Helsinki)" , "Koskelainen Petri (Nokia-NRC/Tampere)" Subject: Re: [XCON] Authorization in conference policy References: <5.2.1.1.0.20040511153947.03a708d0@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040511153947.03a708d0@pop.mcilink.com> Content-Type: text/plain; charset=ISO-8859-1; 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It is true that common-policy does not support "all-except" conditions. But its element does support which can be used to implement a form of blacklist, as exemplified in seciotn 7.1 of common-policy as follows: The next example shows how exceptions are implemented. A request MUST match the domain part and all three exceptions parts in an atomic fashion to be a successful match. example.com joe@example.com tony@example.com mike@example.com I guess the question is, would this be enough in a conferencing scenario? It is beneficial to unify cpcp policy under the common-policy paradigm. Regards, Alex. Alan Johnston wrote: > Hi Aki, > > Thanks for bringing this up. > > I do think it would be worthwhile to do a comparison of presence and > location policy and the conference policy that we are developing in > XCON. If there are major differences or divergences, it would be good > to know what they are (such as the all-except construct you mention > below). > > Having said that, I'm not so certain that conference policy needs to > formally be aligned with the common policy framework, as the > differences between it and the other policies seem to be greater than > the similarities. > > However, if there are some concrete advantages to doing so, I think > the working group should consider this approach. > > Thanks, > Alan Johnston > co-chair XCON > > At 02:46 PM 4/28/2004 +0300, Aki Niemi wrote: > >> Hi All, >> >> Currently, XCAP-CPCP [1] includes the definition of data elements for >> implementing authorization rules and permission rules (privileges) for >> conferences. Along with the definition of those elements, it defines its >> own rule syntax. >> >> Common-policy [2] defines an authorization policy framework, intended >> for use in different applications to control access to data. It includes >> a syntax for common policy rules that are currently being used to >> describe authorization policies in location and SIP presence >> applications. Also, the common policy framework can be extended to >> accomodate other application needs. >> >> In short, this framework defines policy as a set of rules where the >> respective ordering of rules does not matter. Each rule consists of a >> condition for matching some property (e.g., identity of the requestor of >> data); and permissions that are to be applied in case the "condition" >> part has evaluated to true. >> >> It seems natural that the conference policy work would also benefit from >> adopting the common-policy framework. >> >> However, one of the intended usages of conference policy is to control >> the participation to a conference. To expel a participant from an >> ongoing conference, the conference policy would be manipulated in such a >> way that the participant is no longer allowed to participate, effecting >> a removal of that participant from the conference. The need for >> expelling users is also independent of the original admittance policy. >> Even in conferences that have open admittance (i.e. anyone can join), a >> moderator would need to be able to expel users who are disturbing the >> conference, e.g., expel a participant from a chat room for using >> explicit language. >> >> In common-policy point of view, the above would require an "all-except" >> construct, which I believe currently is not allowed in common-policy. >> Question is, can this be worked around, if we were to adopt >> common-policy in the conference policy work? >> >> And if yes, would XCON be willing to see common-policy adopted in the >> conference policy work? >> >> The advantages would include having a unified syntax for policy rules in >> these different applications, including a clear extension model etc. >> >> Disadvantages (pending the resolution of the above issue) would be >> having to rewrite the authorization policy parts of XCAP-CPCP, causing a >> delay. >> >> Thoughts? >> >> Cheers, >> Aki >> >> [1] >> http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xcap-cpcp-usage-02.txt >> >> >> [2] >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt >> >> >> >> _______________________________________________ >> 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 May 12 17:12:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11821 for ; Wed, 12 May 2004 17:12:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0wI-0002IW-MJ for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:06:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CL6sb9008830 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0rJ-0000YX-JX for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 17:01:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11120 for ; Wed, 12 May 2004 17:01:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0rH-0003lJ-GJ for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:01:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0qH-0003GU-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:00:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO0pL-0002m3-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 16:59:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0kn-0007g4-Il; Wed, 12 May 2004 16:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0bF-00055M-Vi for xcon@optimus.ietf.org; Wed, 12 May 2004 16:45:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10215 for ; Wed, 12 May 2004 16:45:07 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0bE-0002sA-2D for xcon@ietf.org; Wed, 12 May 2004 16:45:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0aB-0002Jn-00 for xcon@ietf.org; Wed, 12 May 2004 16:44:04 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BO0Z8-0001k7-00 for xcon@ietf.org; Wed, 12 May 2004 16:42:58 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CKf5k03943; Wed, 12 May 2004 23:41:05 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 23:41:05 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4CKf5mP020670; Wed, 12 May 2004 23:41:05 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 001BM0ru; Wed, 12 May 2004 23:41:02 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CKf2H18757; Wed, 12 May 2004 23:41:02 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 23:41:02 +0300 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] Authorization in conference policy Date: Wed, 12 May 2004 23:41:01 +0300 Message-ID: Thread-Topic: [XCON] Authorization in conference policy Thread-Index: AcQ4W0RP9BckUH0vTjiN4VrZWZ/+vQAAzAEw To: , Cc: , , , , , , , , , , X-OriginalArrivalTime: 12 May 2004 20:41:02.0423 (UTC) FILETIME=[70890E70:01C43861] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I also think that the common policy is such a well though of construct = that CPCP should use it rather than having to invent the similar thing = of its own.=20 The main problem is what Aki raised, i.e. how to block a certain set of = identities from a conference which is otherwise open to anyone. As CPCP = follows the model where kicking-out is done by modifying the = authorization policy, the problem applies also to the case how to kick = out a certain identity from a conference that is otherwise open to = anyone. I've raised the very same (blacklisting for otherwise public info) issue = within SIMPLE for presence. Actually I understand quite well why it is = probably not a good idea for presence (or geoloc). The point is that = they are about protecting the privacy of some data, and even if I block = a set of identities from the data, my data is still compromised to those = people in practice, if I'm willing to give it to ANY other identity. So = even if blacklists are used in many presence systems, I'm able to live = with SIMPLE concensus not to have them. However, I think the conferencing case is still different. There we = could not really live without the all-except construct. In conference = you don't just protect some data, but you also protect the conference = participants from a misbehaving participant. So blocking and kicking out = a single identity is important and useful, even if the same person could = join later with another identity. I think it's like spam filtering: if I = add some address to my spam filter, it certainly does not guarantee that = I don't get any spam from that spammer anymore (since he can use = different identities), but certainly it reduces it at least for a short = while (and conferences for instance normally don't last forever).=20 What Alex is proposing below is what you currently can do with the = common policy, i.e. applying exceptions within domains. However, this is = not adequate in this case, since you can never enumerate all the = possible domains. So something like this is instead needed: joe@example1.com tony@example2.com mike@example3.com I'm NOT proposing to change common policy to accommodate this. As said, = I understand clearly why this is not supported for e.g. geoloc and = presence. I think CPCP should take common policy as it is and make this = change specifically within CPCP. This way we would get (most of) the = benefits of common policy, but could still meet the CPCP and = conferencing requirements. Markus=20 =20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Alex Audu > Sent: 12 May, 2004 21:50 > To: Alan Johnston > Cc: Niemi Aki (Nokia-M/Espoo); XCON WG; Henning Schulzrinne; Jonathan > Rosenberg; jmorris@cdt.org; Hannes.Tschofenig@siemens.com; > Jorge.Cuellar@siemens.com; jmpolk@cisco.com; Ted Hardie; Khartabil > Hisham (Nokia-TP-MSW/Helsinki); Koskelainen Petri (Nokia-NRC/Tampere) > Subject: Re: [XCON] Authorization in conference policy >=20 >=20 > It is true that common-policy does not support "all-except"=20 > conditions. But its element > does support which can be used to implement a form of=20 > blacklist, as exemplified in=20 > seciotn 7.1 of common-policy as follows: >=20 > The next example shows how exceptions are implemented. A=20 > request MUST > match the domain part and all three exceptions parts in an atomic > fashion to be a successful match. >=20 > > example.com > joe@example.com > tony@example.com > mike@example.com > >=20 >=20 > I guess the question is, would this be enough in a=20 > conferencing scenario? > It is beneficial to unify cpcp policy under the common-policy=20 > paradigm. >=20 > Regards, > Alex. >=20 >=20 >=20 > Alan Johnston wrote: >=20 > > Hi Aki, > > > > Thanks for bringing this up. > > > > I do think it would be worthwhile to do a comparison of=20 > presence and=20 > > location policy and the conference policy that we are developing in=20 > > XCON. If there are major differences or divergences, it=20 > would be good=20 > > to know what they are (such as the all-except construct you mention=20 > > below). > > > > Having said that, I'm not so certain that conference policy=20 > needs to=20 > > formally be aligned with the common policy framework, as the=20 > > differences between it and the other policies seem to be=20 > greater than=20 > > the similarities. > > > > However, if there are some concrete advantages to doing so, I think=20 > > the working group should consider this approach. > > > > Thanks, > > Alan Johnston > > co-chair XCON > > > > At 02:46 PM 4/28/2004 +0300, Aki Niemi wrote: > > > >> Hi All, > >> > >> Currently, XCAP-CPCP [1] includes the definition of data=20 > elements for > >> implementing authorization rules and permission rules=20 > (privileges) for > >> conferences. Along with the definition of those elements,=20 > it defines its > >> own rule syntax. > >> > >> Common-policy [2] defines an authorization policy=20 > framework, intended > >> for use in different applications to control access to=20 > data. It includes > >> a syntax for common policy rules that are currently being used to > >> describe authorization policies in location and SIP presence > >> applications. Also, the common policy framework can be extended to > >> accomodate other application needs. > >> > >> In short, this framework defines policy as a set of rules where the > >> respective ordering of rules does not matter. Each rule=20 > consists of a > >> condition for matching some property (e.g., identity of=20 > the requestor of > >> data); and permissions that are to be applied in case the=20 > "condition" > >> part has evaluated to true. > >> > >> It seems natural that the conference policy work would=20 > also benefit from > >> adopting the common-policy framework. > >> > >> However, one of the intended usages of conference policy=20 > is to control > >> the participation to a conference. To expel a participant from an > >> ongoing conference, the conference policy would be=20 > manipulated in such a > >> way that the participant is no longer allowed to=20 > participate, effecting > >> a removal of that participant from the conference. The need for > >> expelling users is also independent of the original=20 > admittance policy. > >> Even in conferences that have open admittance (i.e. anyone=20 > can join), a > >> moderator would need to be able to expel users who are=20 > disturbing the > >> conference, e.g., expel a participant from a chat room for using > >> explicit language. > >> > >> In common-policy point of view, the above would require an=20 > "all-except" > >> construct, which I believe currently is not allowed in=20 > common-policy. > >> Question is, can this be worked around, if we were to adopt > >> common-policy in the conference policy work? > >> > >> And if yes, would XCON be willing to see common-policy=20 > adopted in the > >> conference policy work? > >> > >> The advantages would include having a unified syntax for=20 > policy rules in > >> these different applications, including a clear extension=20 > model etc. > >> > >> Disadvantages (pending the resolution of the above issue) would be > >> having to rewrite the authorization policy parts of=20 > XCAP-CPCP, causing a > >> delay. > >> > >> Thoughts? > >> > >> Cheers, > >> Aki > >> > >> [1] > >>=20 > http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xca p-cpcp-usage-02.txt=20 >> >> >> [2] >> = http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.t= xt=20 >> >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 17:38:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13092 for ; Wed, 12 May 2004 17:38:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1Jg-0007P8-35 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CLV4EF028458 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO16C-0004vL-H2 for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 17:17:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12465 for ; Wed, 12 May 2004 17:17:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO16A-0003P0-AD for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:17:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO15B-0002qy-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:16:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO13l-0001uN-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:14:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0zJ-0002zT-HE; Wed, 12 May 2004 17:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0vl-00022o-AP for xcon@optimus.ietf.org; Wed, 12 May 2004 17:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11369 for ; Wed, 12 May 2004 17:06:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0vj-0005vu-5Z for xcon@ietf.org; Wed, 12 May 2004 17:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0uc-0005Le-00 for xcon@ietf.org; Wed, 12 May 2004 17:05:10 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1BO0tj-0004na-00 for xcon@ietf.org; Wed, 12 May 2004 17:04:15 -0400 Received: from [66.12.12.239] (bdsl.66.12.12.239.gte.net [66.12.12.239]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i4CL6Ju4007119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2004 16:06:19 -0500 Message-ID: <40A2913D.2050808@softarmor.com> Date: Wed, 12 May 2004 16:03:57 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: Jonathan Rosenberg , Gonzalo Camarillo , XCON , Joerg Ott , Keith Drage , Adam Roach Subject: Re: [XCON] Floor Control Draft References: <409B38A8.9070503@ericsson.com> <409B38A8.9070503@ericsson.com> <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Johnston wrote: >> * Its not clear to me that there is really a need for a BFCP URI. BFCP >> doesn't make sense as a stanalone protocol, it needs to be set up by >> something else. So, just like there is no RTP URI, I dont see a need >> for a BFCP URI > > > We need offer/answer and SDP for RTP because there are so many > parameters to negotiate - IP address, port number, codec, bit rate, > etc. I don't see any such negotiation for floor control. I really hope > that the floor control protocol is simple enough that just passing a URI > is sufficient for a client to set up the session. > > I'm interested in others view of the use of SDP. This was the approach > discussed in > http://www.softarmor.com/wgdb/docs/draft-wu-sipping-floor-control-03.txt > and should be considered. . . . > I'm interested in the peer-to-peer uses of floor control you mention. > Currently they are not described in our scenarios document or in the > floor control requirements - can you give some examples? I have a mobile phone behind a NATwall. I INVITE you to a push-to-mumble (TM) session, which requires floor control. I include ine the INVITE a floor control URI. Unfortunately, it's behind my NATwall, so you can't talk to it. I need to know the call failed, and preferably why. As far as I can tell now, the offer-answer negotiation succeeded, then nothing happened. Better yet, the call didn't fail, because the same tricks that got our RTP through the NATwall also got our floor-control through the NATwall. -- Dean _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 17:50:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13660 for ; Wed, 12 May 2004 17:50:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1YH-0004JQ-5b for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CLk9ZB016573 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1Vy-0003TH-CF for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 17:43:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13476 for ; Wed, 12 May 2004 17:43:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO1Vv-0001R4-Sa for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:43:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1Uz-0000wm-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:42:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO1U6-0000RP-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:41:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1RN-0002OM-99; Wed, 12 May 2004 17:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1LJ-0007wb-GA for xcon@optimus.ietf.org; Wed, 12 May 2004 17:32:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12920 for ; Wed, 12 May 2004 17:32:42 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO1LH-0003Ym-5N for xcon@ietf.org; Wed, 12 May 2004 17:32:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1KW-00034u-00 for xcon@ietf.org; Wed, 12 May 2004 17:31:57 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BO1Jd-0002aE-00 for xcon@ietf.org; Wed, 12 May 2004 17:31:01 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CLUVv25699; Thu, 13 May 2004 00:30:31 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 00:30:23 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4CLUNfc002644; Thu, 13 May 2004 00:30:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00o8cz2z; Thu, 13 May 2004 00:30:22 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CLUMH06351; Thu, 13 May 2004 00:30:22 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 00:30:21 +0300 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] Authorization in conference policy Date: Thu, 13 May 2004 00:30:20 +0300 Message-ID: Thread-Topic: [XCON] Authorization in conference policy Thread-Index: AcQ4ZMX8em4TkczeRsmeqhBhB87U+QAAJ0yw To: , , Cc: , , , , , , , , , X-OriginalArrivalTime: 12 May 2004 21:30:21.0771 (UTC) FILETIME=[5471B9B0:01C43868] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,NO_COST,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ted, I guess I agree with all what you say below, but I wasn't able to = conclude whether you think that a) common policy should not be used in CPCP b) common policy could be used but defining all-except for CPCP makes no = sense c) common policy could be used and defining all-except for CPCP might be = OK (I'm not trying to make a mess with the all-except stuff in all possible = cases. I actually like the common policy work a lot, I just think that = many conferencing use cases make c) a reasonable approach.) Some comments also inline.=20 Ted Hardie wrote: >=20 > At 11:41 PM +0300 05/12/2004, wrote: > > > >However, I think the conferencing case is still different. There we=20 > >could not really live without the all-except construct. In=20 > >conference you don't just protect some data, but you also protect=20 > >the conference participants from a misbehaving participant. So=20 > >blocking and kicking out a single identity is important and useful,=20 > >even if the same person could join later with another identity. >=20 > And I think that is the crux of the question. In previous=20 > discussions, > the idea that a misbehaving individual could mint an identity at > essentially no cost meant that creating an "any except" construct > didn't actually prevent much. =20 Well, I still think that in most cases I have in mind getting a new = identity with no cost is not possible, so I would surely have use for = all-except in general. But I guess that was discussed separately = already. > Your argument seems to say > that even though it doesn't prevent them from accessing the > conference, the *act* of kicking them out and blocking them > has some value in and of itself. >=20 Obviously not if the participants that are kicked out always appear 1 = second later again with a new disguise ;) However, I assume that there = still would be non-zero cost for getting the new identity, especially = measured in time - so even if the person is persistent it maybe possible = for the moderator to do _something_ about him. =20 > Speaking personally, it seems most likely to be valuable only > in cases where 1) the individual must mint a new identity (i.e. cannot > easily use a different, existing identity) and 2) this takes=20 > sufficient > time that the conference proceeds without disruption either to its > conclusion or for some significant period of time. I'm not sure about > the percentage of cases likely to meet both 1 and 2. >=20 OK, I guess we agree here. I certainly have no exact figures, but I = believe, and have seen in chat systems such as IRC, that these = conditions are in many cases fulfilled. And what is the alternative? Not = being able to do anything in any case (than to close the conference for = new entries)? > I guess one question that follows from this is a use case question: > how often will a conference organizer be able to close a conference > *completely* to new participants at some point in the conference? > That would provide a pretty obvious counter to newly minted=20 > identities, > but it seems like it might be a small subset of likely cases.=20 > Any data > on that? > regards, > Ted Hardie >=20 >=20 >=20 Markus _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 17:55:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13806 for ; Wed, 12 May 2004 17:55:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1cD-00054s-O6 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:50:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CLoDTV019513 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1Yu-0004Px-9d for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 17:46:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13564 for ; Wed, 12 May 2004 17:46:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO1Yr-0002wU-S1 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1Xt-0002Ql-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:45:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO1Wt-0001vU-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:44:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1RO-0002Oe-CO; Wed, 12 May 2004 17:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1NG-0000SP-5y for xcon@optimus.ietf.org; Wed, 12 May 2004 17:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12969 for ; Wed, 12 May 2004 17:34:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO1ND-0004XX-Ns for xcon@ietf.org; Wed, 12 May 2004 17:34:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1MK-00043l-00 for xcon@ietf.org; Wed, 12 May 2004 17:33:48 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BO1Lf-0003Ze-00 for xcon@ietf.org; Wed, 12 May 2004 17:33:07 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4CLVBbt026803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 May 2004 17:31:12 -0400 (EDT) Message-ID: <40A2979E.70101@cs.columbia.edu> Date: Wed, 12 May 2004 17:31:10 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie CC: Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, aki.niemi@nokia.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.12.100548 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I guess one question that follows from this is a use case question: > how often will a conference organizer be able to close a conference > *completely* to new participants at some point in the conference? > That would provide a pretty obvious counter to newly minted identities, > but it seems like it might be a small subset of likely cases. Any data > on that? I think this is fairly common - once a conference has been in progress for a while, it's natural to close to door to random strangers. In some cases, I suspect that there will be a human in the loop - "send email to conference-admin@foo.com and we'll add you to the member list". If you get a person that you have to kick out because they are misbehaving, you might assume that this person has some incentive to re-join and continue his tirades. It seems like that the better model for this is to affect mixing, and simply withdraw the floor from the person. This is needed in any event for the common case where somebody has put their phone on mute, not realizing that this generates music-on-hold (or walked out of the room, leaving the microphone on, which then captures street noise). What cases are there that mixing policy wouldn't have the same effect than explicit removal? Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 17:55:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13823 for ; Wed, 12 May 2004 17:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1cO-00055h-Pq for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:50:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CLoOIW019565 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 17:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1Zp-0004RY-CV for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 17:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13581 for ; Wed, 12 May 2004 17:47:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO1Zm-0003RH-T8 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:47:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1Yo-0002w5-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:46:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO1Xp-0002PV-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 17:45:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1RP-0002Oy-95; Wed, 12 May 2004 17:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0vY-000227-UG for xcon@optimus.ietf.org; Wed, 12 May 2004 17:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11353 for ; Wed, 12 May 2004 17:06:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0vW-0005u4-PW for xcon@ietf.org; Wed, 12 May 2004 17:06:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0uO-0005Jc-00 for xcon@ietf.org; Wed, 12 May 2004 17:04:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BO0tP-0004H7-00 for xcon@ietf.org; Wed, 12 May 2004 17:03:55 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4CL2MU9013071; Wed, 12 May 2004 14:02:22 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4CL2FKB019066; Wed, 12 May 2004 14:02:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Wed, 12 May 2004 14:02:14 -0700 To: , , From: Ted Hardie Subject: RE: [XCON] Authorization in conference policy Cc: , , , , , , , , , 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_COST autolearn=no version=2.60 At 11:41 PM +0300 05/12/2004, wrote: > >However, I think the conferencing case is still different. There we >could not really live without the all-except construct. In >conference you don't just protect some data, but you also protect >the conference participants from a misbehaving participant. So >blocking and kicking out a single identity is important and useful, >even if the same person could join later with another identity. And I think that is the crux of the question. In previous discussions, the idea that a misbehaving individual could mint an identity at essentially no cost meant that creating an "any except" construct didn't actually prevent much. Your argument seems to say that even though it doesn't prevent them from accessing the conference, the *act* of kicking them out and blocking them has some value in and of itself. Speaking personally, it seems most likely to be valuable only in cases where 1) the individual must mint a new identity (i.e. cannot easily use a different, existing identity) and 2) this takes sufficient time that the conference proceeds without disruption either to its conclusion or for some significant period of time. I'm not sure about the percentage of cases likely to meet both 1 and 2. I guess one question that follows from this is a use case question: how often will a conference organizer be able to close a conference *completely* to new participants at some point in the conference? That would provide a pretty obvious counter to newly minted identities, but it seems like it might be a small subset of likely cases. Any data on that? regards, Ted Hardie _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 20:49:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22799 for ; Wed, 12 May 2004 20:49:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4NY-0007p4-5M for xcon-archive@odin.ietf.org; Wed, 12 May 2004 20:47:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D0lG1x030070 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 20:47:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4G0-0005By-GS for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 20:39:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21764 for ; Wed, 12 May 2004 20:39:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO4Fy-00047Z-AP for xcon-web-archive@ietf.org; Wed, 12 May 2004 20:39:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO4F0-0003Yq-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 20:38:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO4E7-00031H-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 20:37:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO44B-0001pw-2x; Wed, 12 May 2004 20:27:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO2d1-0000hT-VC for xcon@optimus.ietf.org; Wed, 12 May 2004 18:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17313 for ; Wed, 12 May 2004 18:55:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO2cy-00068g-RB for xcon@ietf.org; Wed, 12 May 2004 18:55:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO2c6-0005cb-00 for xcon@ietf.org; Wed, 12 May 2004 18:54:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1BO2bC-0004v9-00 for xcon@ietf.org; Wed, 12 May 2004 18:53:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4CMpcV2014088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2004 15:51:39 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4CMpXrZ017691; Wed, 12 May 2004 15:51:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <40A2979E.70101@cs.columbia.edu> References: <40A2979E.70101@cs.columbia.edu> Date: Wed, 12 May 2004 15:51:32 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [XCON] Authorization in conference policy Cc: Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, aki.niemi@nokia.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 5:31 PM -0400 05/12/2004, Henning Schulzrinne wrote: >It seems like that the better model for this is to affect mixing, >and simply withdraw the floor from the person. This is needed in any >event for the common case where somebody has put their phone on >mute, not realizing that this generates music-on-hold (or walked out >of the room, leaving the microphone on, which then captures street >noise). > >What cases are there that mixing policy wouldn't have the same >effect than explicit removal? > It allows them to continue to listen to the call, which means it doesn't do the same thing as the boot. I assume there are cases where this is required or desirable. Ted _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed May 12 21:17:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24334 for ; Wed, 12 May 2004 21:17:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4k5-00063M-3r for xcon-archive@odin.ietf.org; Wed, 12 May 2004 21:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D1AXwX023264 for xcon-archive@odin.ietf.org; Wed, 12 May 2004 21:10:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4j4-0005ha-Oz for xcon-web-archive@optimus.ietf.org; Wed, 12 May 2004 21:09:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23956 for ; Wed, 12 May 2004 21:09:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO4j2-0004bu-9W for xcon-web-archive@ietf.org; Wed, 12 May 2004 21:09:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO4iA-00044Z-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 21:08:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO4hA-0003Vp-00 for xcon-web-archive@ietf.org; Wed, 12 May 2004 21:07:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4Zz-0002tg-Co; Wed, 12 May 2004 21:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4R1-00015l-Ah for xcon@optimus.ietf.org; Wed, 12 May 2004 20:50:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23039 for ; Wed, 12 May 2004 20:50:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO4Qy-0002b9-TZ for xcon@ietf.org; Wed, 12 May 2004 20:50:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO4Q1-00021l-00 for xcon@ietf.org; Wed, 12 May 2004 20:49:50 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BO4Oq-0001QW-00 for xcon@ietf.org; Wed, 12 May 2004 20:48:36 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4D0gubt008386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 May 2004 20:42:57 -0400 (EDT) Message-ID: <40A2C490.70806@cs.columbia.edu> Date: Wed, 12 May 2004 20:42:56 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie CC: Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, aki.niemi@nokia.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: <40A2979E.70101@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.12.100579 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > It allows them to continue to listen to the call, which means it doesn't > do the > same thing as the boot. I assume there are cases where this is required > or desirable. Wouldn't that depend on the capability of the media mixer configuration? _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 00:57:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02904 for ; Thu, 13 May 2004 00:57:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO8Et-00050G-UF for xcon-archive@odin.ietf.org; Thu, 13 May 2004 00:54:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D4sZMm019226 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 00:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO8CB-0004QZ-85 for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 00:51:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02723 for ; Thu, 13 May 2004 00:51:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO8C8-0003rl-J4 for xcon-web-archive@ietf.org; Thu, 13 May 2004 00:51:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO8BF-0003NG-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 00:50:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO8AY-0002sX-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 00:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO83h-00039G-GG; Thu, 13 May 2004 00:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO82P-0002rF-18 for xcon@optimus.ietf.org; Thu, 13 May 2004 00:41:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02398 for ; Thu, 13 May 2004 00:41:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO82M-0006iH-DN for xcon@ietf.org; Thu, 13 May 2004 00:41:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO81N-0006Dw-00 for xcon@ietf.org; Thu, 13 May 2004 00:40:38 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BO80c-0005Nw-00 for xcon@ietf.org; Thu, 13 May 2004 00:39:50 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4D4dabo000586; Thu, 13 May 2004 00:39:36 -0400 (EDT) Message-ID: <40A2FBEA.2090609@dynamicsoft.com> Date: Thu, 13 May 2004 00:39:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: Gonzalo Camarillo , XCON , Joerg Ott , Keith Drage , Adam Roach Subject: Re: [XCON] Floor Control Draft References: <409B38A8.9070503@ericsson.com> <409B38A8.9070503@ericsson.com> <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Johnston wrote: > Jonathan, >> * Its not clear to me that there is really a need for a BFCP URI. BFCP >> doesn't make sense as a stanalone protocol, it needs to be set up by >> something else. So, just like there is no RTP URI, I dont see a need >> for a BFCP URI > > > We need offer/answer and SDP for RTP because there are so many > parameters to negotiate - IP address, port number, codec, bit rate, > etc. I don't see any such negotiation for floor control. I really hope > that the floor control protocol is simple enough that just passing a URI > is sufficient for a client to set up the session. I dont think the choice of URI or not is driven by the amount of parameters. After all, a URI can have lots and lots of parameters. The choice is based on whether connecting to a floor control server makes sense outside of the context of any specific call or conference. I dont think it does. I think there will always be some kind of call or confernece, and as such, I see little value for a URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 01:04:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03311 for ; Thu, 13 May 2004 01:04:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO8N6-0006jL-Ox for xcon-archive@odin.ietf.org; Thu, 13 May 2004 01:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D5345o025867 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 01:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO8I6-00060t-KX for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 00:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02965 for ; Thu, 13 May 2004 00:57:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO8I3-0006q8-RA for xcon-web-archive@ietf.org; Thu, 13 May 2004 00:57:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO8H2-0006L6-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 00:56:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO8GP-0005ph-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 00:56:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO8CP-0004Sf-Sa; Thu, 13 May 2004 00:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO87J-0003pv-AX for xcon@optimus.ietf.org; Thu, 13 May 2004 00:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02547 for ; Thu, 13 May 2004 00:46:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO87G-0001Oj-Kl for xcon@ietf.org; Thu, 13 May 2004 00:46:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO86H-0000ul-00 for xcon@ietf.org; Thu, 13 May 2004 00:45:42 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BO85o-0000Q5-00 for xcon@ietf.org; Thu, 13 May 2004 00:45:12 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4D4j0bo000590; Thu, 13 May 2004 00:45:01 -0400 (EDT) Message-ID: <40A2FD2E.5000507@dynamicsoft.com> Date: Thu, 13 May 2004 00:44:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Bennett CC: xcon@ietf.org Subject: Re: [XCON] Floor Control Draft References: <002501c43851$4c81add0$2f90fea9@DBSTNR11> In-Reply-To: <002501c43851$4c81add0$2f90fea9@DBSTNR11> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Chris Bennett wrote: > The RTP position has mostly actively been championed by ourselves, > although it has had some support from other companies such as Nortel and > Huawei, and has some outside academic support -- see > http://research.ac.upc.es/EW2004/papers/144.pdf . Our argument is that > there are some FCP transactions which interact with the media, notably > those that signal new speakers, end of talk bursts, and, most > importantly, queue status updates, RTP already provides a facility for signaling the speaker - its the CSRC, and the RTCP CNAME provides a mapping of that SSRC to a specific user. Talkspurt indications are provided by the market bits. I don't see either of those as floor control, though clearly they belong in RTP. For the other floor control primitives, I don't see the specific need for coupling with the media stream. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 03:59:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26506 for ; Thu, 13 May 2004 03:59:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOB6v-0006Dq-Pa for xcon-archive@odin.ietf.org; Thu, 13 May 2004 03:58:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D7wXUq023918 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 03:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOB2E-0005RP-TL for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 03:53:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26265 for ; Thu, 13 May 2004 03:53:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOB2C-0002uG-EK for xcon-web-archive@ietf.org; Thu, 13 May 2004 03:53:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOB1C-0002NO-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 03:52:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOB00-0001Lt-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 03:51:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAwl-0004J9-Il; Thu, 13 May 2004 03:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAsd-0003b6-E4 for xcon@optimus.ietf.org; Thu, 13 May 2004 03:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25930 for ; Thu, 13 May 2004 03:43:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOAsa-0005Vj-LS for xcon@ietf.org; Thu, 13 May 2004 03:43:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOArl-0004yI-00 for xcon@ietf.org; Thu, 13 May 2004 03:42:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BOAqK-0003rk-00 for xcon@ietf.org; Thu, 13 May 2004 03:41:24 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4D7Zgv13692; Thu, 13 May 2004 10:35:42 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 10:35:21 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4D7ZLoP012339; Thu, 13 May 2004 10:35:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 004xmWxJ; Thu, 13 May 2004 10:34:48 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4D7YgH28638; Thu, 13 May 2004 10:34:42 +0300 (EET DST) Received: from nokia.com ([172.21.81.135]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 10:34:39 +0300 Message-ID: <40A3250E.6000604@nokia.com> Date: Thu, 13 May 2004 10:34:38 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Henning Schulzrinne CC: Ted Hardie , Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: <40A2979E.70101@cs.columbia.edu> In-Reply-To: <40A2979E.70101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2004 07:34:39.0445 (UTC) FILETIME=[BFB3B850:01C438BC] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Henning Schulzrinne wrote: >> I guess one question that follows from this is a use case question: >> how often will a conference organizer be able to close a conference >> *completely* to new participants at some point in the conference? >> That would provide a pretty obvious counter to newly minted identities, >> but it seems like it might be a small subset of likely cases. Any data >> on that? > > > I think this is fairly common - once a conference has been in progress > for a while, it's natural to close to door to random strangers. In some > cases, I suspect that there will be a human in the loop - "send email to > conference-admin@foo.com and we'll add you to the member list". Or set true in the authz policy, which would mean the moderator gets a notification of someone trying to join (using the conference-info events), and can reactively authorize that person. However, this sort of admittance policy is well within the bounds of what common-policy already supports. No problem there. > If you get a person that you have to kick out because they are > misbehaving, you might assume that this person has some incentive to > re-join and continue his tirades. Certainly. Kicking someone off the conference is nothing more than a slap on the hand. Kicking and banning someone is a little bit stronger, but still not enough to guarantee good riddance of the misbehaving individual. There is certain analogy here with IRC, where both /kick and /kick-ban are operations a channel operator can invoke. In IRC coming up with a new nick bears close to zero cost, yet both of these operations are needed and AFAIK, used in the real world. I think we need the same features in CPCP since I think text chats are also one form of conferencing. > It seems like that the better model for this is to affect mixing, and > simply withdraw the floor from the person. This is needed in any event > for the common case where somebody has put their phone on mute, not > realizing that this generates music-on-hold (or walked out of the room, > leaving the microphone on, which then captures street noise). > > What cases are there that mixing policy wouldn't have the same effect > than explicit removal? At least the experience is different for the participant being removed. Anyway, I think the requirement for CPCP to be able to expel participants is quite clear. I think this is also orthogonal to any mixing policy requirements. Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 04:52:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28720 for ; Thu, 13 May 2004 04:52:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBqW-0007Ri-VP for xcon-archive@odin.ietf.org; Thu, 13 May 2004 04:45:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D8jeIC028617 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 04:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBlu-0006PU-99 for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 04:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28192 for ; Thu, 13 May 2004 04:40:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOBlr-00043K-FU for xcon-web-archive@ietf.org; Thu, 13 May 2004 04:40:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOBkm-0003Ts-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 04:39:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOBjn-0002vs-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 04:38:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBcN-00041h-IS; Thu, 13 May 2004 04:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBTR-00026f-HB for xcon@optimus.ietf.org; Thu, 13 May 2004 04:21:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27330 for ; Thu, 13 May 2004 04:21:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOBTO-0001nH-M9 for xcon@ietf.org; Thu, 13 May 2004 04:21:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOBSL-0001Gd-00 for xcon@ietf.org; Thu, 13 May 2004 04:20:42 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BOBRL-0000iu-00 for xcon@ietf.org; Thu, 13 May 2004 04:19:39 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4D8Hrk17723; Thu, 13 May 2004 11:17:53 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 11:17:49 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4D8HnNZ031464; Thu, 13 May 2004 11:17:49 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00cC9XL4; Thu, 13 May 2004 11:17:48 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4D8HXH24115; Thu, 13 May 2004 11:17:33 +0300 (EET DST) Received: from nokia.com ([172.21.81.135]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 11:17:28 +0300 Message-ID: <40A32F19.7090407@nokia.com> Date: Thu, 13 May 2004 11:17:29 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Aki Niemi CC: ext Henning Schulzrinne , Ted Hardie , Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: <40A2979E.70101@cs.columbia.edu> <40A3250E.6000604@nokia.com> In-Reply-To: <40A3250E.6000604@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2004 08:17:28.0965 (UTC) FILETIME=[BB415B50:01C438C2] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Replying to self...] ext Aki Niemi wrote: >> I think this is fairly common - once a conference has been in progress >> for a while, it's natural to close to door to random strangers. In >> some cases, I suspect that there will be a human in the loop - "send >> email to conference-admin@foo.com and we'll add you to the member list". > > > Or set true in the authz policy, which > would mean the moderator gets a notification of someone trying to join > (using the conference-info events), and can reactively authorize that > person. > > However, this sort of admittance policy is well within the bounds of > what common-policy already supports. No problem there. Except that this doesn't quite work. If I'd like to grant "allow" to a named few, and request that all others need confirmation before joining, I would need a rule construct like this: bill@example.com mark@example.com lisa@example.com true true Now, expelling someone so that not even confirmation is granted would require the second rule to be modified like this: joe@example.com true ...which is again an "all-except" construct. Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 07:18:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05230 for ; Thu, 13 May 2004 07:18:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOE2d-0008QH-FK for xcon-archive@odin.ietf.org; Thu, 13 May 2004 07:06:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DB6Jvq032377 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 07:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOE1G-00087T-6p for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 07:04:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04833 for ; Thu, 13 May 2004 07:04:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOE1B-0003QG-Vs for xcon-web-archive@ietf.org; Thu, 13 May 2004 07:04:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOE0C-0002sp-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 07:03:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BODzE-0002Ke-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 07:02:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BODxV-0007g1-SV; Thu, 13 May 2004 07:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BODtZ-0006q2-Of for xcon@optimus.ietf.org; Thu, 13 May 2004 06:56:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04417 for ; Thu, 13 May 2004 06:56:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BODtV-0006lD-FN for xcon@ietf.org; Thu, 13 May 2004 06:56:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BODsU-0006E3-00 for xcon@ietf.org; Thu, 13 May 2004 06:55:51 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly08b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BODra-0005BX-00 for xcon@ietf.org; Thu, 13 May 2004 06:54:54 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly08b.srv.mailcontrol.com (MailControl) with SMTP id i4DArlX2006560; Thu, 13 May 2004 11:54:24 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Thu, 13 May 2004 11:54:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C438D8.74025040" Date: Thu, 13 May 2004 11:52:58 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF3F4@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Refer Thread-Index: AcQ42JVlr91CsW1rSbm4+MRoDKKPtQ== From: "Chris Boulton" To: Cc: X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Subject: [XCON] Refer 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C438D8.74025040 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hisham, =20 Just a quick question. What was the reason for including the 'refer' attribute in the ACL element . Wouldn't this fit better in the DL list? =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C438D8.74025040 Content-Type: text/html; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hisham,

 

         &n= bsp;  Just a quick question.  What was the reason for including the ‘refer’ attribute in the ACL element <ACL-target-URI>.  Wouldn’t this fit better in the DL list= ?

 

Chris.

 

 

------------------------------------------------
Chris Boulton
Ubiquity Software

 

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601
------------------------------------------------

 

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C438D8.74025040-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 07:43:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06163 for ; Thu, 13 May 2004 07:43:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEan-0006T0-50 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 07:41:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DBfbrb024859 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 07:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEaF-0006Jk-9S for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 07:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06098 for ; Thu, 13 May 2004 07:41:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOEaE-0006op-IJ for xcon-web-archive@ietf.org; Thu, 13 May 2004 07:41:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOEZI-0006Ie-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 07:40:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOEYf-0005mT-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 07:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEWM-0005Gw-KR; Thu, 13 May 2004 07:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEL0-0003f1-Q8 for xcon@optimus.ietf.org; Thu, 13 May 2004 07:25:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05645 for ; Thu, 13 May 2004 07:25:15 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOEKy-0006H4-4A for xcon@ietf.org; Thu, 13 May 2004 07:25:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOEJv-0005jZ-00 for xcon@ietf.org; Thu, 13 May 2004 07:24:12 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BOEJG-0005Bp-00 for xcon@ietf.org; Thu, 13 May 2004 07:23:30 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DBNNH15675; Thu, 13 May 2004 14:23:23 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 14:23:12 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4DBNCTj002946; Thu, 13 May 2004 14:23:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00rZ883m; Thu, 13 May 2004 14:23:11 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DBNAH14525; Thu, 13 May 2004 14:23:10 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 14:23:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C438DC.AB7C6849" Date: Thu, 13 May 2004 14:23:09 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797AD3@esebe019.ntc.nokia.com> Thread-Topic: Refer Thread-Index: AcQ42JVlr91CsW1rSbm4+MRoDKKPtQAAz7/A To: Cc: X-OriginalArrivalTime: 13 May 2004 11:23:09.0921 (UTC) FILETIME=[ABC85510:01C438DC] Subject: [XCON] RE: Refer 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C438DC.AB7C6849 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is still one of the open issues on my list. I'm planning on sending = emails with open issues soon (in fact I planned to do so tomorrow). =20 Just a quick answer: There are 2 reason I put the refer in the ACL: - the focus is not really dialling out to the users, but merely = referring them. DL tells the focus to dial-out. I.e create a session. - The users then dial in and therefore an entry in the ACL is needed = anyway to give them permission to dial in. If we place the refer in the = DL, then we need 2 entries for every refer that makes modifying the = conference policy a little more difficult. =20 Regards, Hisham -----Original Message----- From: ext Chris Boulton [mailto:cboulton@ubiquity.com] Sent: 13.May.2004 13:53 To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: xcon@ietf.org Subject: Refer Hisham, =20 Just a quick question. What was the reason for including = the 'refer' attribute in the ACL element . Wouldn't = this fit better in the DL list? =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 =20 This message has been scanned for viruses by = MailControl, a service from = BlackSpider Technologies. ------_=_NextPart_001_01C438DC.AB7C6849 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This=20 is still one of the open issues on my list. I'm planning on sending = emails with=20 open issues soon (in fact I planned to do=20 so tomorrow).
 
Just a=20 quick answer: There are 2 reason I put the refer in the=20 ACL:
- the=20 focus is not really dialling out to the users, but merely referring = them. DL=20 tells the focus to dial-out. I.e create a session.
- The=20 users then dial in and therefore an entry in the ACL is needed = anyway to=20 give them permission to dial in. If we place the refer in the DL, then = we need 2=20 entries for every refer that makes modifying the conference policy a = little more=20 difficult.
 
Regards,
Hisham
-----Original Message-----
From: ext Chris Boulton=20 [mailto:cboulton@ubiquity.com]
Sent: 13.May.2004 = 13:53
To:=20 Khartabil Hisham (Nokia-TP-MSW/Helsinki)
Cc:=20 xcon@ietf.org
Subject: Refer

Hisham,

 

           = =20 Just a quick question.  What was the reason for including the = ‘refer’=20 attribute in the ACL element <ACL-target-URI>.  = Wouldn’t this fit=20 better in the DL list?

 

Chris.

 

 

------------------------------------------------
= Chris=20 Boulton
Ubiquity=20 Software

 

Tel : +44 (0) = 1633765600
Fax :=20 +44 (0) 1633765601=20
------------------------------------------------

 

 

 



This = message has been=20 scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C438DC.AB7C6849-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 08:58:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09612 for ; Thu, 13 May 2004 08:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFiY-0002uN-2v for xcon-archive@odin.ietf.org; Thu, 13 May 2004 08:53:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DCrgAG011179 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 08:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFb5-0001rZ-51 for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 08:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09094 for ; Thu, 13 May 2004 08:45:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOFb3-0002c7-Ra for xcon-web-archive@ietf.org; Thu, 13 May 2004 08:45:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOFa3-00024j-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 08:44:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOFYo-00015H-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 08:43:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFWG-0000cl-S6; Thu, 13 May 2004 08:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFD1-0004Qr-VK for xcon@optimus.ietf.org; Thu, 13 May 2004 08:21:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07700 for ; Thu, 13 May 2004 08:21:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOFD0-0004ct-Tg for xcon@ietf.org; Thu, 13 May 2004 08:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOFC7-000465-00 for xcon@ietf.org; Thu, 13 May 2004 08:20:11 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BOFBA-0003YM-00 for xcon@ietf.org; Thu, 13 May 2004 08:19:12 -0400 Received: from cs.columbia.edu (pool-138-89-99-128.mad.east.verizon.net [138.89.99.128]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4DCIxbt025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2004 08:19:00 -0400 (EDT) Message-ID: <40A367AB.8000102@cs.columbia.edu> Date: Thu, 13 May 2004 08:18:51 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Aki Niemi CC: Ted Hardie , Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: <40A2979E.70101@cs.columbia.edu> <40A3250E.6000604@nokia.com> In-Reply-To: <40A3250E.6000604@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.12.100579 X-PerlMx-Spam: Gauge=XXIIIIIII, Probability=27%, Report='Y_NJABL_DUL 3, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, RELAY_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A random idea: make the admission policy stateful and design a special condition that says "any URI && if admitted for the first time, then [admit without confirmation|confirm|..." The person kicked out would fail that test and get the special individualized treatment (such as confirmation required or rejection). The drawback is that the higher-layer bouncer application would have to add the good guys to the explicit user list to make it easier for them to rejoin if they should leave temporarily, but that's probably unavoidable anyway if the initial admission requires confirmation. (You wouldn't want to have to manually approve each person in a large group each time they come and go.) The advantage of tracking admission count is that this also simplifies the "ask when joining the conference for the first time, get admitted automatically if rejoining". Aki Niemi wrote: > > > ext Henning Schulzrinne wrote: > >>> I guess one question that follows from this is a use case question: >>> how often will a conference organizer be able to close a conference >>> *completely* to new participants at some point in the conference? >>> That would provide a pretty obvious counter to newly minted identities, >>> but it seems like it might be a small subset of likely cases. Any data >>> on that? >> >> >> >> I think this is fairly common - once a conference has been in progress >> for a while, it's natural to close to door to random strangers. In >> some cases, I suspect that there will be a human in the loop - "send >> email to conference-admin@foo.com and we'll add you to the member list". > > > Or set true in the authz policy, which > would mean the moderator gets a notification of someone trying to join > (using the conference-info events), and can reactively authorize that > person. > > However, this sort of admittance policy is well within the bounds of > what common-policy already supports. No problem there. > >> If you get a person that you have to kick out because they are >> misbehaving, you might assume that this person has some incentive to >> re-join and continue his tirades. > > > Certainly. Kicking someone off the conference is nothing more than a > slap on the hand. Kicking and banning someone is a little bit stronger, > but still not enough to guarantee good riddance of the misbehaving > individual. > > There is certain analogy here with IRC, where both /kick and /kick-ban > are operations a channel operator can invoke. In IRC coming up with a > new nick bears close to zero cost, yet both of these operations are > needed and AFAIK, used in the real world. > > I think we need the same features in CPCP since I think text chats are > also one form of conferencing. > >> It seems like that the better model for this is to affect mixing, and >> simply withdraw the floor from the person. This is needed in any event >> for the common case where somebody has put their phone on mute, not >> realizing that this generates music-on-hold (or walked out of the >> room, leaving the microphone on, which then captures street noise). >> >> What cases are there that mixing policy wouldn't have the same effect >> than explicit removal? > > > At least the experience is different for the participant being removed. > Anyway, I think the requirement for CPCP to be able to expel > participants is quite clear. I think this is also orthogonal to any > mixing policy requirements. > > Cheers, > Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 13:29:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26035 for ; Thu, 13 May 2004 13:29:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJmd-0000Sj-Su for xcon-archive@odin.ietf.org; Thu, 13 May 2004 13:14:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DHEB85001777 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 13:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJWP-0004J1-6Y for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 12:57:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23333 for ; Thu, 13 May 2004 12:57:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOJWN-00052K-HJ for xcon-web-archive@ietf.org; Thu, 13 May 2004 12:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJVU-0004Uo-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 12:56:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOJUf-0003wX-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 12:55:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJSF-0003Hn-1o; Thu, 13 May 2004 12:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJNe-00026t-N0 for xcon@optimus.ietf.org; Thu, 13 May 2004 12:48:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22378 for ; Thu, 13 May 2004 12:48:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOJNc-0007Iz-Uq for xcon@ietf.org; Thu, 13 May 2004 12:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJLh-0006ZI-00 for xcon@ietf.org; Thu, 13 May 2004 12:46:21 -0400 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1BOJKx-00062J-00 for xcon@ietf.org; Thu, 13 May 2004 12:45:35 -0400 Received: from unknown (HELO DBSTNR11) (cjbennett@sbcglobal.net@66.123.255.50 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 13 May 2004 16:42:55 -0000 Message-ID: <004501c43909$4cf0e0c0$2f90fea9@DBSTNR11> Reply-To: "Chris Bennett" From: "Chris Bennett" To: "Jonathan Rosenberg" Cc: References: <002501c43851$4c81add0$2f90fea9@DBSTNR11> <40A2FD2E.5000507@dynamicsoft.com> Subject: Re: [XCON] Floor Control Draft Date: Thu, 13 May 2004 09:42:37 -0700 Organization: Vista Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathon -- Thank you for your comments. > RTP already provides a facility for signaling the speaker - its the > CSRC, and the RTCP CNAME provides a mapping of that SSRC to a specific > user. Talkspurt indications are provided by the market bits. I don't see > either of those as floor control, though clearly they belong in RTP. On FCP design, I agree that a change in RTP CSRC could be used by the FCP as an implicit signal for a change of floorholder if it is present. However, the CSRC is only supplied if there is a mixing function, and in PoC no mixing occurs, so there is no CSRC. The interpretation of the marker bit is profile-dependent and the FCP needs a means for indicating the end of talkburst that is profile-independent. > For the other floor control primitives, I don't see the specific need > for coupling with the media stream. I agree that there is no logical coupling between queue status returns with media. That's not our claim. Our concern is that there is a resource contention interaction when they are transmitted concurrently, and that this is usually the case. In PoC, the resource is the airlink forward channel. The effect of the contention is to add depth to the media jitter buffer in the client, which adds to end-end latency. In most environments this effect is too slight to matter, but on the very narrowband airlinks people want to use for PoC it adds over 50 ms of jitter, unless you use link-layer header compression techniques, or the RTP piggybacking technique when header compression is not available. Currently the latency of packet-based PoC systems is well over a second, and OMA has recognised this by choosing performance targets of 1.6 seconds. But circuit-based PoC systems are very much faster, a few hundred ms, and several carriers are choosing circuit-based systems for this reason. So we see the OMA specs as very much worst-case numbers, and the circuit-based latency as defining the target we should be aiming for. 50+ ms is a significant fraction of this. Our view is that if packet-based PoC systems are to become competitive it is necessary to squeeze out every unnecessary delay at every layer of the system -- including the FCP -- from day 1. I hope that makes the argument clearer. Chris _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 17:47:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18640 for ; Thu, 13 May 2004 17:47:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONy0-0001Da-HK for xcon-archive@odin.ietf.org; Thu, 13 May 2004 17:42:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLgCRx004680 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 17:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONw4-00088b-IR for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 17:40:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18083 for ; Thu, 13 May 2004 17:40:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BONw1-0007Ck-Tu for xcon-web-archive@ietf.org; Thu, 13 May 2004 17:40:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONuS-0006Qm-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 17:38:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BONsD-0005FD-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 17:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONkZ-0003bQ-U3; Thu, 13 May 2004 17:28:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONR5-00069a-1S for xcon@optimus.ietf.org; Thu, 13 May 2004 17:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14384 for ; Thu, 13 May 2004 17:08:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BONR2-0000AL-O6 for xcon@ietf.org; Thu, 13 May 2004 17:08:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONPM-0006tz-00 for xcon@ietf.org; Thu, 13 May 2004 17:06:25 -0400 Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx with esmtp (Exim 4.12) id 1BONNm-0005Wf-00 for xcon@ietf.org; Thu, 13 May 2004 17:04:46 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HXO0088S7V366@firewall.mci.com> for xcon@ietf.org; Thu, 13 May 2004 21:04:16 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HXO00A017V1TC@pmismtp02.mcilink.com>; Thu, 13 May 2004 21:04:16 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.122.128]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HXO00ACB7V0K0@pmismtp02.mcilink.com>; Thu, 13 May 2004 21:04:14 +0000 (GMT) Date: Thu, 13 May 2004 16:04:12 -0500 From: Alan Johnston Subject: Re: [XCON] Floor Control Draft In-reply-to: <40A2913D.2050808@softarmor.com> X-Sender: Alan.Johnston@pop.mcilink.com To: Dean Willis Cc: Jonathan Rosenberg , Gonzalo Camarillo , XCON , Joerg Ott , Keith Drage , Adam Roach Message-id: <5.2.1.1.0.20040512163534.03ad08a8@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> <409B38A8.9070503@ericsson.com> <409B38A8.9070503@ericsson.com> <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 04:03 PM 5/12/2004 -0500, Dean Willis wrote: >Alan Johnston wrote: > >>>* Its not clear to me that there is really a need for a BFCP URI. BFCP >>>doesn't make sense as a stanalone protocol, it needs to be set up by >>>something else. So, just like there is no RTP URI, I dont see a need for >>>a BFCP URI >> >>We need offer/answer and SDP for RTP because there are so many parameters >>to negotiate - IP address, port number, codec, bit rate, etc. I don't >>see any such negotiation for floor control. I really hope that the floor >>control protocol is simple enough that just passing a URI is sufficient >>for a client to set up the session. >>I'm interested in others view of the use of SDP. This was the approach >>discussed in >>http://www.softarmor.com/wgdb/docs/draft-wu-sipping-floor-control-03.txt >>and should be considered. > > . . . > >>I'm interested in the peer-to-peer uses of floor control you mention. >>Currently they are not described in our scenarios document or in the >>floor control requirements - can you give some examples? > >I have a mobile phone behind a NATwall. I INVITE you to a push-to-mumble >(TM) session, which requires floor control. I include ine the INVITE a >floor control URI. Unfortunately, it's behind my NATwall, so you can't >talk to it. I need to know the call failed, and preferably why. As far as >I can tell now, the offer-answer negotiation succeeded, then nothing happened. OK - so the UA used STUN/TURN and provides public transport addresses in the SDP - hence the media session works. The same approach could be used by the UA to ensure that the floor control URI it creates is routable. Alternatively, the URI could be made routable using DNS ( e.g. bfcp:myserver.dyndns.org). If the UA is smart enough to "fix" the IP addresses in the SDP, it can be smart enough to fix them in the floor control URI. In my mind, the more compelling reason is tighter coupling with the SIP dialog. If the floor control channel is setup using SIP it is more tightly coupled than if it is completely separate. However, taking this argument further, it suggest that a CPCP control channel should be negotiated using SIP instead of using XCAP (a separate protocol)... Do others have thoughts, opinions on this? It is important we decide this issue soon... Thanks, Alan Johnston MCI sip:alan@sipstation.com >Better yet, the call didn't fail, because the same tricks that got our RTP >through the NATwall also got our floor-control through the NATwall. > >-- >Dean > >_______________________________________________ >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 May 13 18:03:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19504 for ; Thu, 13 May 2004 18:03:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOOBp-0005P8-Vs for xcon-archive@odin.ietf.org; Thu, 13 May 2004 17:56:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLuTAA020774 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 17:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOO8p-0004I2-Dr for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 17:53:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19051 for ; Thu, 13 May 2004 17:53:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOO8m-00073A-MA for xcon-web-archive@ietf.org; Thu, 13 May 2004 17:53:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOO7v-0006WU-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 17:52:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOO6o-0005yg-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 17:51:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONyp-0001hp-14; Thu, 13 May 2004 17:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONue-0007gk-JO for xcon@optimus.ietf.org; Thu, 13 May 2004 17:38:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17865 for ; Thu, 13 May 2004 17:38:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BONuc-0006Ro-29 for xcon@ietf.org; Thu, 13 May 2004 17:38:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONsc-0005Yc-00 for xcon@ietf.org; Thu, 13 May 2004 17:36:38 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BONok-0003t0-00 for xcon@ietf.org; Thu, 13 May 2004 17:32:38 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4DLWRbo001046; Thu, 13 May 2004 17:32:27 -0400 (EDT) Message-ID: <40A3E949.3050400@dynamicsoft.com> Date: Thu, 13 May 2004 17:31:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Bennett CC: xcon@ietf.org Subject: Re: [XCON] Floor Control Draft References: <002501c43851$4c81add0$2f90fea9@DBSTNR11> <40A2FD2E.5000507@dynamicsoft.com> <004501c43909$4cf0e0c0$2f90fea9@DBSTNR11> In-Reply-To: <004501c43909$4cf0e0c0$2f90fea9@DBSTNR11> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Bennett wrote: > Jonathon -- > > Thank you for your comments. > > >>RTP already provides a facility for signaling the speaker - its the >>CSRC, and the RTCP CNAME provides a mapping of that SSRC to a specific >>user. Talkspurt indications are provided by the market bits. I don't see >>either of those as floor control, though clearly they belong in RTP. > > > On FCP design, I agree that a change in RTP CSRC could be used by the FCP as > an implicit signal for a change of floorholder if it is present. However, > the CSRC is only supplied if there is a mixing function, and in PoC no > mixing occurs, so there is no CSRC. I think this depends on your definition of mixing. Its "easy" mixing, but its mixing in that the PTT server is acting as a receiver for all media streams, is combining them in some way (in this case, discarding some), and sending the results out to the other participants. > > The interpretation of the marker bit is profile-dependent and the FCP needs > a means for indicating the end of talkburst that is profile-independent. Why? > > >>For the other floor control primitives, I don't see the specific need >>for coupling with the media stream. > > > I agree that there is no logical coupling between queue status returns with > media. That's not our claim. > > Our concern is that there is a resource contention interaction when they are > transmitted concurrently, and that this is usually the case. In PoC, the > resource is the airlink forward channel. The effect of the contention is to > add depth to the media jitter buffer in the client, which adds to end-end > latency. > > In most environments this effect is too slight to matter, but on the very > narrowband airlinks people want to use for PoC it adds over 50 ms of jitter, > unless you use link-layer header compression techniques, or the RTP > piggybacking technique when header compression is not available. There can, of course, be other packets that might get delivered to the mobile from other applications. You have an implicit assumption that the PTT application server is, basically, the only entity transmitting packets to the mobile, and therefore you are having it perform functions traditionally done at the link layer - namely the scheduling of packets on the link. I think a better approach is to keep the protocols separate, and deal with these kinds of schedulign issues for a particular link either through custom architectures and/or link layer techniques. In this particular case, if you co-locate the floor control server and the PTT application server, I don't see why the server could not simply send the floor control packet first, and once sent, then start delivering the media packets. Of course link compression would be an even better approach. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 13 21:14:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29727 for ; Thu, 13 May 2004 21:14:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORES-0004yL-ND for xcon-archive@odin.ietf.org; Thu, 13 May 2004 21:11:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1BOr4019103 for xcon-archive@odin.ietf.org; Thu, 13 May 2004 21:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORBi-00047A-C0 for xcon-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:08:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29493 for ; Thu, 13 May 2004 21:08:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BORBf-0002CO-Qn for xcon-web-archive@ietf.org; Thu, 13 May 2004 21:08:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORAe-0001eK-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 21:07:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOR9T-0000pL-00 for xcon-web-archive@ietf.org; Thu, 13 May 2004 21:06:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOR3U-0001Tf-K0; Thu, 13 May 2004 21:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQxe-0008SB-K2 for xcon@optimus.ietf.org; Thu, 13 May 2004 20:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28712 for ; Thu, 13 May 2004 20:54:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOQxc-0001qS-4F for xcon@ietf.org; Thu, 13 May 2004 20:54:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQwX-0001HN-00 for xcon@ietf.org; Thu, 13 May 2004 20:52:54 -0400 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1BOQvg-0000jH-00 for xcon@ietf.org; Thu, 13 May 2004 20:52:00 -0400 Received: from unknown (HELO DBSTNR11) (cjbennett@sbcglobal.net@67.115.8.150 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 14 May 2004 00:51:05 -0000 Message-ID: <001b01c4394d$803db810$2f90fea9@DBSTNR11> Reply-To: "Chris Bennett" From: "Chris Bennett" To: "Jonathan Rosenberg" Cc: References: <002501c43851$4c81add0$2f90fea9@DBSTNR11> <40A2FD2E.5000507@dynamicsoft.com> <004501c43909$4cf0e0c0$2f90fea9@DBSTNR11> <40A3E949.3050400@dynamicsoft.com> Subject: Re: [XCON] Floor Control Draft Date: Thu, 13 May 2004 17:50:49 -0700 Organization: Vista Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit See CJB inline ----- Original Message ----- From: "Jonathan Rosenberg" To: "Chris Bennett" Cc: Sent: Thursday, May 13, 2004 2:31 PM Subject: Re: [XCON] Floor Control Draft > > > Chris Bennett wrote: > > > Jonathon -- CJB: (Sorry for misspelling your name) > > > > Thank you for your comments. > > > > > >>RTP already provides a facility for signaling the speaker - its the > >>CSRC, and the RTCP CNAME provides a mapping of that SSRC to a specific > >>user. Talkspurt indications are provided by the market bits. I don't see > >>either of those as floor control, though clearly they belong in RTP. > > > > > > On FCP design, I agree that a change in RTP CSRC could be used by the FCP as > > an implicit signal for a change of floorholder if it is present. However, > > the CSRC is only supplied if there is a mixing function, and in PoC no > > mixing occurs, so there is no CSRC. > > I think this depends on your definition of mixing. Its "easy" mixing, > but its mixing in that the PTT server is acting as a receiver for all > media streams, is combining them in some way (in this case, discarding > some), and sending the results out to the other participants. > CJB: Not really. The point of the FCP in PTT is to ensure that there is at most one media stream transmitted to the PTT Server at any given time. Its a bit of a stretch to call this "mixing". CJB: In any case there sees to be general agreement within OMA that changes of floorholder should be explicitly signalled and identified within the FCP, not by relying on RTP, and I have no quarrel with that view. > > > > The interpretation of the marker bit is profile-dependent and the FCP needs > > a means for indicating the end of talkburst that is profile-independent. > > Why? CJB: Why which? CJB: Why does the FCP need to indicate the end of talk burst? So that the server knows that the floor is released. CJB: Why does the FCP need to do this in a way that is media profile independent? Two reasons: Because making any aspect of the FCP media-profile-dependent makes it expensive to apply it to new media profiles. Because profiles may exist which do not provide a means. > > > > > > >>For the other floor control primitives, I don't see the specific need > >>for coupling with the media stream. > > > > > > I agree that there is no logical coupling between queue status returns with > > media. That's not our claim. > > > > Our concern is that there is a resource contention interaction when they are > > transmitted concurrently, and that this is usually the case. In PoC, the > > resource is the airlink forward channel. The effect of the contention is to > > add depth to the media jitter buffer in the client, which adds to end-end > > latency. > > > > In most environments this effect is too slight to matter, but on the very > > narrowband airlinks people want to use for PoC it adds over 50 ms of jitter, > > unless you use link-layer header compression techniques, or the RTP > > piggybacking technique when header compression is not available. > > There can, of course, be other packets that might get delivered to the > mobile from other applications. You have an implicit assumption that the > PTT application server is, basically, the only entity transmitting > packets to the mobile, and therefore you are having it perform functions > traditionally done at the link layer - namely the scheduling of packets > on the link. CJB: For many lowend PoC terminals, dedicated to the application, this will in fact be the case. I agree that there are many others where it won't be the case, but this is an economically important case. > > I think a better approach is to keep the protocols separate, and deal > with these kinds of schedulign issues for a particular link either > through custom architectures and/or link layer techniques. > CJB: Custom architectures are not an option, and for many carriers link layer compression techniques are very likely to be available only some time after PoC rollout. CJB: As a practical matter, solutions which cause CDMA supplemental channels or additional GPRS TBFs to be activated sporadically are not looked on favourably by many carriers, so there is a strong incentive to exert tight control over the link-level bandwidth budget. > In this particular case, if you co-locate the floor control server and > the PTT application server, I don't see why the server could not simply > send the floor control packet first, and once sent, then start > delivering the media packets. CJB: Because in queued FCP systems your request usually only gets queued if someone else is already speaking, and the server doesn't know how long the talk burst is going to last. > > Of course link compression would be an even better approach. > CJB: Agreed, where available. Of course, the temptation will be to use the bandwidth gained to reduce voice latency and improve quality, so its still desirable to keep other activities under control. > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 14 03:51:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04367 for ; Fri, 14 May 2004 03:51:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXR4-0003Um-H0 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 03:48:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7moJi013436 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 03:48:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXNJ-0002lC-I3 for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:44:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04124 for ; Fri, 14 May 2004 03:44:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXNH-0001aI-70 for xcon-web-archive@ietf.org; Fri, 14 May 2004 03:44:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXME-00014K-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 03:43:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOXLL-0000Y3-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 03:42:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXFo-0000y9-1W; Fri, 14 May 2004 03:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXDq-0000OC-8s for xcon@optimus.ietf.org; Fri, 14 May 2004 03:35:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03541 for ; Fri, 14 May 2004 03:35:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXDn-0003sh-LD for xcon@ietf.org; Fri, 14 May 2004 03:35:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXCC-0002iM-00 for xcon@ietf.org; Fri, 14 May 2004 03:33:29 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BOXAh-00025o-00 for xcon@ietf.org; Fri, 14 May 2004 03:31:55 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4E7Vak14951; Fri, 14 May 2004 10:31:37 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 10:31:06 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4E7V6Ku020397; Fri, 14 May 2004 10:31:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00vQHCNg; Fri, 14 May 2004 10:31:05 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4E7V3H18184; Fri, 14 May 2004 10:31:03 +0300 (EET DST) Received: from nokia.com ([10.162.252.165]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 10:31:02 +0300 Message-ID: <40A475B5.6020007@nokia.com> Date: Fri, 14 May 2004 10:31:01 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Alan Johnston CC: Dean Willis , Jonathan Rosenberg , Gonzalo Camarillo , XCON , Joerg Ott , Keith Drage , Adam Roach Subject: Re: [XCON] Floor Control Draft References: <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> <409B38A8.9070503@ericsson.com> <409B38A8.9070503@ericsson.com> <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> <5.2.1.1.0.20040512163534.03ad08a8@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040512163534.03ad08a8@pop.mcilink.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2004 07:31:02.0618 (UTC) FILETIME=[68E04BA0:01C43985] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Alan Johnston wrote: > In my mind, the more compelling reason is tighter coupling with the SIP > dialog. If the floor control channel is setup using SIP it is more > tightly coupled than if it is completely separate. However, taking > this argument further, it suggest that a CPCP control channel should be > negotiated using SIP instead of using XCAP (a separate protocol)... The CPCP control channel isn't supposed to be negotiated using XCAP. XCAP is used to implement that control channel, but the XCAP URI is delivered to the participants of a conference by other means. One such mean is the conference-info event package, and we've also proposed using the Call-Info header to "negotiate" that channel using SIP. See: http://www.ietf.org/internet-drafts/draft-khartabil-sip-policy-uri-call-info-purpose-00.txt > Do others have thoughts, opinions on this? It is important we decide > this issue soon... I think negotiating the floor control channel in the offer-answer is the way to go. How often will a floor control server be behind a NAT anyway? Cheers, Aki > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > >> Better yet, the call didn't fail, because the same tricks that got our >> RTP through the NATwall also got our floor-control through the NATwall. >> >> -- >> Dean >> >> _______________________________________________ >> 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 Fri May 14 04:38:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07346 for ; Fri, 14 May 2004 04:38:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOY9o-0005ck-6N for xcon-archive@odin.ietf.org; Fri, 14 May 2004 04:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E8Z4Dk021618 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 04:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOY3k-0004UJ-7s for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 04:28:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06898 for ; Fri, 14 May 2004 04:28:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOY3h-0001gq-Co for xcon-web-archive@ietf.org; Fri, 14 May 2004 04:28:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOY2g-0001B9-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 04:27:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOY1b-0000St-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 04:26:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXz8-0003L5-1q; Fri, 14 May 2004 04:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXx2-0002qf-Vx for xcon@optimus.ietf.org; Fri, 14 May 2004 04:21:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06275 for ; Fri, 14 May 2004 04:21:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXx0-0005W6-2Z for xcon@ietf.org; Fri, 14 May 2004 04:21:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXvH-0004lF-00 for xcon@ietf.org; Fri, 14 May 2004 04:20:04 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BOXuQ-00045D-00 for xcon@ietf.org; Fri, 14 May 2004 04:19:10 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4E8IXLc028816; Fri, 14 May 2004 03:18:33 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.196]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLP7WN; Fri, 14 May 2004 03:18:08 -0500 Message-ID: <40A480D9.8010002@ericsson.com> Date: Fri, 14 May 2004 11:18:33 +0300 X-Sybari-Trust: 617140c5 08d63d2e 09a997dd 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Alan Johnston , Dean Willis , Jonathan Rosenberg , XCON , Joerg Ott , Keith Drage , Adam Roach Subject: Re: [XCON] Floor Control Draft References: <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> <409B38A8.9070503@ericsson.com> <409B38A8.9070503@ericsson.com> <5.2.1.1.0.20040512094245.03abc1b0@pop.mcilink.com> <5.2.1.1.0.20040512163534.03ad08a8@pop.mcilink.com> <40A475B5.6020007@nokia.com> In-Reply-To: <40A475B5.6020007@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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, as a side note, regarding the discussion SDP vs. CPCP to establish the floor control channel, if we eventually decide to use SDP, one thing we will need to discuss is whether we want to use URIs (the bfcp draft currently defines them) or a more RTP-looking approach (i.e., providing the port number like we do with RTP streams). Just in case we decided to use the latter, I have just submitted a new revision of the comedia draft to MMUSIC. http://standards.ericsson.net/gonzalo/papers/draft-ietf-mmusic-sdp-comedia-06.txt Note that this does not mean that I am advocating its use for floor control. I am just trying to be on the safe side covering one of the possible outcomes of this discussion. In any case, the comedia draft is needed for other stuff, regardless of our decision regarding floor control. If you have any comments on the comedia draft, please send them to me and to the MMUSIC mailing list. Regards, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 14 06:56:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13893 for ; Fri, 14 May 2004 06:56:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaHo-0004t6-TP for xcon-archive@odin.ietf.org; Fri, 14 May 2004 06:51:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EApSX1018788 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 06:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaGU-0004UG-Gb for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:50:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13641 for ; Fri, 14 May 2004 06:50:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaGQ-0003cv-DX for xcon-web-archive@ietf.org; Fri, 14 May 2004 06:50:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaFR-000382-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 06:49:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOaEW-0002cD-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 06:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaBd-0003Hl-BT; Fri, 14 May 2004 06:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOa9m-0002sx-5C for xcon@optimus.ietf.org; Fri, 14 May 2004 06:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13236 for ; Fri, 14 May 2004 06:43:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOa9i-00006f-2U for xcon@ietf.org; Fri, 14 May 2004 06:43:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOa8a-0007P3-00 for xcon@ietf.org; Fri, 14 May 2004 06:41:57 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly05b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BOa7n-0006YY-00 for xcon@ietf.org; Fri, 14 May 2004 06:41:08 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05b.srv.mailcontrol.com (MailControl) with SMTP id i4EAeJSo012691; Fri, 14 May 2004 11:40:32 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Fri, 14 May 2004 11:40:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4399E.F0B4C25C" Date: Fri, 14 May 2004 11:33:47 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B2AE@gbnewp0758m.eu.ubiquity.net> Thread-Topic: BFCP Thread-Index: AcQ5nvCc97WVrFZaT2yelBkpHeniFQ== From: "Chris Boulton" To: "Gonzalo Camarillo" , , "Drage, Keith (Keith)" Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Subject: [XCON] BFCP 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, SUBJ_ALL_CAPS autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C4399E.F0B4C25C Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Guys, I'd like to start by saying I like this approach. I do have the similar concerns regarding the clarity of components such as user-ID + floor-ID are obtained from framework BUT this has already been raised. =20 Could you clear up some confusion regarding chair operations. Section 9.2 reads: =20 'The client MUST set the Request ID value of the REQUEST-ID TLV to a random number. The Request ID value is used by the chair to match this ChairAction message with the responses received from the floor control server'. =20 Yet later on in this section reads: =20 The chair MUST identify the floor the instructions in the message apply to using a FLOOR-ID TLV. Additionally, the chair MUST identify the floor request the instructions in the message apply to using a REQUEST-ID and a USER-ID TLVs. =20 Maybe I'm getting confused, but I see this as conflicting. I don't see how the chair request is correlated with floor request? =20 Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C4399E.F0B4C25C Content-Type: text/html; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Guys,

         &n= bsp;  I’d like to start by saying I like this approach.  I do have the similar concerns regarding the clarity of components such as user-ID + floor-ID are= obtained from framework BUT this has already been raised.

 

Could you clear up some confusion regarding chair operat= ions.  Section 9.2 reads:

 

‘The client MUST set the Request ID value of the REQUEST-ID TLV to a

   random number. The Request ID value is used= by the chair to match

   this ChairAction message with the responses received from the floor

   control server’.

 

Yet later on in this section reads:

 

The chair MUST identify the floor the instructions in the message

   apply to using a FLOOR-ID TLV. Additionally, the chair MUST identify

   the floor request the instructions in the message apply to using a

   REQUEST-ID and a USER-ID TLVs.

 

Maybe I’m getting confused, but I see this as conflicting.  I don’t see how the chair request is correlated wi= th floor request?

 

Regards,

 

Chris.

 

 

------------------------------------------------
Chris Boulton
Ubiquity Software

 

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601
------------------------------------------------

 

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C4399E.F0B4C25C-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 14 10:07:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23779 for ; Fri, 14 May 2004 10:07:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdJy-00061U-D1 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 10:05:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EE5sHh023149 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 10:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdIE-0005IK-Tu for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 10:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23452 for ; Fri, 14 May 2004 10:04:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOdIC-0000GR-NV for xcon-web-archive@ietf.org; Fri, 14 May 2004 10:04:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOdHG-0007ZW-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 10:03:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOdGU-00075P-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 10:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdEI-0002Bh-LA; Fri, 14 May 2004 10:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOdBV-0001oe-St for xcon@optimus.ietf.org; Fri, 14 May 2004 09:57:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23024 for ; Fri, 14 May 2004 09:57:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOdBT-0004YV-7g for xcon@ietf.org; Fri, 14 May 2004 09:57:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOdAS-00042S-00 for xcon@ietf.org; Fri, 14 May 2004 09:56:06 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly03b.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1BOd9K-00034K-00 for xcon@ietf.org; Fri, 14 May 2004 09:54:54 -0400 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly03b.srv.mailcontrol.com (MailControl) with SMTP id i4EDrGER027614; Fri, 14 May 2004 14:54:06 +0100 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-b.mailcontrol.com [217.68.146.190]) with SMTP; Fri, 14 May 2004 14:54:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C439BA.A2962E5F" Date: Fri, 14 May 2004 14:52:02 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B2AF@gbnewp0758m.eu.ubiquity.net> Thread-Topic: CPCP Review Thread-Index: AcQ5uqJpkh6LHA/NSHGJe1QQlLaQOA== From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Subject: [XCON] CPCP Review 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C439BA.A2962E5F Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hisham, Petri, =20=20=20=20=20=20=20=20=20=20=20=20 Had a good read of this and have included some feedback. To be honest the majority are NITS, so nothing really to stress about. Hope they are helpful. =20 Regards, =20 Chris. =20 =20 Section 1. =20 Reads: A centralized serve, called focus, can expel..... And should read: A centralized server, called focus, can expel.... =20 Reads: However, in many cases it is useful to have a standardised conference policy elements such as access control lists and a standardised protocol means to manipulate them. And should read: However, in many cases it is useful to have standardised conference policy elements such as access control lists and a standardised protocol means to manipulate them. =20 Reads: One application area which has already adopted XCAP is the manipulation of event lists [9]. Should read: One application area which has already adopted XCAP is the manipulation of presence lists [9]. =20 Section 3. =20 Reads: Access control list (ACL) defines users who can join to a conference. Users may have allowed, blocked, pending or expelled status in the list. Each conference has its own ACL. Should read: Access control list (ACL) defines users who can join to a unique conference instance. Users may have allowed, blocked, pending or expelled status in the list. Each conference has its own ACL. =20 Reads: Conference participant is a user who has on-going session (e.g. SIP dialog) with the conference focus. Should read: Conference participant is a user who has an on-going session (e.g.SIP dialog) with the conference focus. =20 Reads: Privilege control list (PCL) defines privileges for a user. Each user in a conference may have a different list of privileges and each conference has its own PCL. =20 Section 4. =20 Reads: Elements or attributes from unknown namespaces MUST be ignored. The conference policy is build up using multiple namespaces: Should read: Elements or attributes from unknown namespaces MUST be ignored. The conference policy is built up using multiple namespaces: =20 Reads: This element includes informational describing the conference, e.g. for search purposes. Should read: This element includes information describing the conference, e.g. for search purposes. =20 Reads: "urn:ietf:params:xml:ns:conference-fp": This optional namespace is for the floor control policy. It defines the element. =20 Question: This is the only subsection that does not give a brief descriptive summary. =20 Section 4.2.1 =20 Reads: is an optional. Should read: is an optional element. =20 Section 4.2.4 =20 Reads: This can be used in the where the allowed URIs are wild-carded and the user wants to explicitly block one potential participant, whose URI falls within the wildcarded URIs, from joining. Should read: This element can be used where the allowed URIs are wild-carded and the user wants to explicitly block one potential participant, whose URI falls within the wildcarded URIs, from joining. =20 Reads: "Most-specific expression wins" policy is used if overlapping rules are found. Basically, this means that user specific rule is searched first and if it is not found, then most specific wildcard rule is utilized. =20 Question: What happens to conflicting values e.g. wildcard user matches in allowed list BUT wild card domain matches in the blocked list? =20 Section 4.2.5 =20=20=20 Reads: The element is mandatory and has its own XML namespace. It defines which users has what privileges. Should read: The element is mandatory and has its own XML namespace. It defines users and their associated privileges. =20 Section 4.2.7 =20 Heading Reads:=20 (Security Control) element Should read: (Security Control) element =20 Reads: The conference security settings start with the mandatory >SC> element. Should read: The conference security settings start with the mandatory element. =20 Section 4.2.8 =20 The element in the element is optional and, if present, dictates the maximum number of users who can have the floor at one time. The optional indicates the URI of the moderator. It MUST be set if the attribute moderator-controlled is set to "true". =20 Question: Should we be specifying a default for this when not present? E.g. 1. =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C439BA.A2962E5F Content-Type: text/html; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hisham, Petri,

         &n= bsp; 

         &n= bsp;            = ;  Had a good read of this and have included some feedback.  To be honest the majority are NITS, so nothing really to stress about.  Hope they are helpful.

 

Regards,

 

Chris.

 

 

Section 1.

 

Reads:

A centralized serve, called focus, can expel…..

And should read:

A centralized server, called focus, can expel….

 

Reads:

However, in many cases it is useful to have a standardis= ed conference policy elements such as access control lists and a standardised protocol means to manipulate them.

And should read:

However, in many cases it is useful to have standardised conference policy elements such as access control lists and a standardised protocol means to manipulate them.

 

Reads:

One application area which has already adopted XCAP is t= he manipulation of event lists [9].

Should read:

One application area which has already adopted XCAP is t= he manipulation of presence lists [9].

 

Section 3.

 

Reads:

Access control list (ACL) defines users who can join to = a conference. Users may have allowed, blocked, pending or expelled status in the list. Ea= ch conference has its own ACL.

Should read:

Access control list (ACL) defines users who can join to = a unique conference instance. Users may have allowed, blocked, pending or expelled status in the list. Each conference has its own ACL.

 

Reads:

Conference participant is a user who has on-going sessio= n (e.g. SIP dialog) with the conference focus.

Should read:

Conference participant is a user who has an on-going ses= sion (e.g.SIP dialog) with the conference focus.

 

Reads:

Privilege control list (PCL) defines privileges for a us= er.  Each user in a conference may have a different list of privileges and each conference has its own PCL.

 

Section 4.

 

Reads:

Elements or attributes from unknown namespaces MUST be ignored. The conference policy is build up using multiple namespaces:

Should read:

Elements or attributes from unknown namespaces MUST be ignored. The conference policy is built up using multiple namespaces:

 

Reads:

This element includes informational describing the conference, e.g. for search purposes.

Should read:

This element includes information describing the confere= nce, e.g. for search purposes.

 

Reads:

"urn:ietf:params:xml:ns:conference-fp": This optional namespace is for the floor control policy. It defines the <Conf= erence-floor-policy> element.

 

Question: This is the only subsection that does not give= a brief descriptive summary.

 

Section 4.2.1

 

Reads:

<Max-participant-count> is an optional.

Should read:

<Max-participant-count> is an optional element.

 

Section 4.2.4

 

Reads:

This can be used in the where the allowed URIs are wild-= carded and the user wants to explicitly block one potential participant, whose URI falls within the wildcarded URIs, from joining.

Should read:

This element can be used where the allowed URIs are wild= -carded and the user wants to explicitly block one potential participant, whose URI falls within the wildcarded URIs, from joining.

 

Reads:

"Most-specific expression wins" policy is used= if overlapping rules are found. Basically, this means that user specific rule = is searched first and if it is not found, then most specific wildcard rule is = utilized.

 

Question: What happens to conflicting values e.g. wildca= rd user matches in allowed list BUT wild card domain matches in the blocked list?

 

Section 4.2.5

   

Reads:

The <PCL> element is mandatory and has its own XML namespace. It defines which users has what privileges.

Should read:

The <PCL> element is mandatory and has its own XML namespace. It defines users and their associated privileges.<= /p>

 

Section 4.2.7

 

Heading Reads:

<SC> (Security Control) element

Should read:

<Conference-SC> (Security Control) element<= /font>

 

Reads:

The conference security settings start with the mandatory >SC> element.

Should read:

The conference security settings start with the mandator= y <Conference-SC> element.

 

Section 4.2.8

 

The <Max-floor-users> element in the <Floor> element is optional and, if present, dictates the maximum number of users w= ho can have the floor at one time. The optional <Moderator-URI> indicates the URI of the moderator. It MUST be set if the attribute moderator-control= led is set to "true".

 

Question: Should we be specifying a default for this when not present?  E.g. 1.

 

------------------------------------------------
Chris Boulton
Ubiquity Software

 

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601
------------------------------------------------

 

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C439BA.A2962E5F-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 14 11:27:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27687 for ; Fri, 14 May 2004 11:27:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeYy-0007uD-0z for xcon-archive@odin.ietf.org; Fri, 14 May 2004 11:25:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EFPRCn030387 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 11:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeSq-0006fi-Ix for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 11:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27346 for ; Fri, 14 May 2004 11:19:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeSn-00068a-5b for xcon-web-archive@ietf.org; Fri, 14 May 2004 11:19:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeRp-0005cZ-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 11:18:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOeQn-00057S-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 11:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeI6-0004Tf-Uk; Fri, 14 May 2004 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOeGN-00041l-H9 for xcon@optimus.ietf.org; Fri, 14 May 2004 11:06:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26915 for ; Fri, 14 May 2004 11:06:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOeGK-0007ZO-Qp for xcon@ietf.org; Fri, 14 May 2004 11:06:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeFQ-000750-00 for xcon@ietf.org; Fri, 14 May 2004 11:05:19 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BOeEb-0006an-00 for xcon@ietf.org; Fri, 14 May 2004 11:04:25 -0400 Received: from solstice (ew-dsl-81-171-8-127.eweka.nl [81.171.8.127]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i4EFYpWB033673 for ; Fri, 14 May 2004 15:34:55 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200405141534.i4EFYpWB033673@smtp.eweka.nl> From: "Arnoud van Wijk" To: Date: Fri, 14 May 2004 17:04:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C439D5.83753390" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQ5xLzUBN/CQYIlTNuwyGD+v7TKnA== Subject: [XCON] Interactive text scenarios for the conference scenarios draft 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C439D5.83753390 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello everybody, I promised to give the xconners here a few scenarios for the conference scenarios draft (draft-ietf-xcon-conference-scenarios-00.txt). And this also explains in what way Interactive text is used in the conference. If you have questions.. Shoot! Text conference: Interactive text as described in RFC 2793. Real time text (interactive text) should be available in the main conference as well in the sidebar. The nature of Interactive text is real-time, character by character and in real-time. Since it uses RTP (as described in RFC 2793 and 2793-bis), there is no problem to add interactive text to the conference call. This fits perfectly to the Total Conversation, where Audio, Video and Interactive text are available for the user. Scenarios for the main conference: Interactive text acting as subtitles of the voice in the conference, this is useful for non native speakers of the language used in the conference. In this way those users will be able to follow the conference and fall back to the interactive text if they do not understand a phrase or for clarification. Another group of users will be the hearing impaired and speech impaired users. In this way, they can fully participate to the conference. All the voice conversations will be available in text. Conversation typed in interactive text can be transcoded into audio conversation using a text to speech application. Users needing to participate to 2 conference calls simultaneoulsy, can opt for one conference in audio/video and one only in Interactive text. This allows the user to focus on the main conference with the audio and track the second conference in text. Users who are at the time of the conference in a public place and do not want the surrounding people to be disturbed (or eavedrop the conference) can decide to continue part or the whole conference call in interactive text. For example receiving audio and video and sending interactive text instead of sending audio. Or when there is too much background noise, also choose to receive interactive text. Scenarios for Text Chat messaging in Chat rooms and conference sidebars During a conference call, there is sometimes a need for discussing items with one or more conference attendees separately. To avoid distractions from the main conference, such sidebar conversation is most likely text based. The Sidebar text chat can be Instant Messaging like and Interactive text like. Depending on the user preferences. Interactive text to IM can be fully transparant. IM to Interactive text is a bit more complicated due the difference of text delivery (streaming versus a block of text). If the latter is done, thus IM to Interactive text, some indicator should be given to the Interactive text user that the text will come in bursts. Most likely sidebar users start by default in IM mode and when the IM session becomes more a conversation, both users can deside to switch to Interactive text. Suggested additions in the conference scenarios draft (draft-ietf-xcon-conference-scenarios-00.txt) in addition to the above scenarios: 3.5 Advanced conference features. (page 6) Add: Changing media anytime during the conference., during the course of a conference, a participant may be able to choose a different media stream in addition to the media streams currently present in the conference. For example, a participant initially joined the conference and discovers that he or she is unable to understand the language properly. (non native speaker or hearing impaired). The participant then requests an Interactive text stream with the same conversation found in the audio stream, same language or an alternative language (for transcription and/or closed captions). It must be possible to invoke a transcoding service in the conference if the participant requires one. The transcoding service can for example be speech to text and vice versa as well speech to video signlanguage and vice versa. Page 7: Change in the fragment describing sideconference/sidebars (3rd paragraph). Last line, Or an audio or video conference may have a text sidebar using RFC 2793 Interactive texting OR Instant messaging. Depending on the preference of the conference participant. 4. Scenarios for media policy control (page 8) Add: The scenarios apply to audio conference as well as to total conversation conferences where video and interactive text are included in the conference. 4.3 Conference sidebar scenario (page 10) Add: (2nd paragraph) User invites participants... If the new participant uses a transcoded media stream in the main conference, this media stream must be available in the sidebar if it belongs to the sidebar selected media. For example when an English audio stream is moved to the sidebar, the transcoded Spanish text stream must also move to the sidebar. Even if the sidebar creator selected the main conference English audio stream. Add: (after the 4th paragraph) Sidebar participants with the right authorization must be able to use interactive text in addition to or replacing the audio stream in the sidebar. If desired. Even if the main conference did not use a transcoded interactive text stream. 4.7 (page 12), change: last line: Note that a real-time transcription/closed captioning service can provide a similar window in which audio media is converted to text. Into: Note that a real-time transcription/closed captioning service can provide a similar window in which audio media is converted into interactive text. 4.9 Text Sidebars (page 12) My advice is to make a distinction between the 2 forms of text communication. Interactive text and Instant messaging. Change: 'Text or instant messaging sidebars' Into: 'Interactive text or Instant Messaging sidebars' Change: 'For example, a conference which is providing anonymity/ aliases to participants can also provide anonymous/alias sidebars. A text sidebar can also benefit from other security/logging/recording services provided by the focus.' Into: For example, ... provided by the focus. And another use of a text sidebar is a text only conversation/discussion between 2 or more conference participants while at the same time following the main conference without being distracted by additional audio. Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 ------=_NextPart_000_002C_01C439D5.83753390 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello everybody,

I promised to give the xconners here a few scenarios for the = conference scenarios draft = (draft-ietf-xcon-conference-scenarios-00.txt).

And this also explains in what way Interactive text is used in = the conference. If you have questions…. = Shoot!

 

Text conference:

 

Interactive text as described in RFC = 2793.

 

 

Real time text (interactive text) should be available in the = main conference as well in the sidebar.

 

The nature of Interactive text is real-time, character by = character and in real-time. Since it uses RTP (as described in RFC 2793 and 2793-bis), = there is no problem to add interactive text to the conference call. =

This fits perfectly to the Total Conversation, where Audio, = Video and Interactive text are available for the user. =

 

Scenarios for the main conference:

 

Interactive text acting as subtitles of the voice in the = conference, this is useful for non native speakers of the language used in the = conference. In this way those users will be able to follow the conference and fall = back to the interactive text if they do not understand a phrase or for = clarification.

 

Another group of users will be the hearing impaired and speech = impaired users. In this way, they can fully participate to the conference. All = the voice conversations will be available in text. Conversation typed in = interactive text can be transcoded into audio conversation using a text to speech = application.

 

Users needing to participate to 2 conference calls = simultaneoulsy, can opt for one conference in audio/video and one only in Interactive text. = This allows the user to focus on the main conference with the audio and track = the second conference in text.

 

Users who are at the time of the conference in a public place = and do not want the surrounding people to be disturbed (or eavedrop the = conference) can decide to continue part or the whole conference call in interactive = text. For example receiving audio and video and sending interactive text = instead of sending audio.

Or when there is too much background noise, also choose to = receive interactive text.

 

Scenarios for Text Chat messaging in Chat rooms and conference = sidebars

 

During a conference call, there is sometimes a need for = discussing items with one or more conference attendees separately. To avoid = distractions from the main conference, such sidebar conversation is most likely text = based.

The Sidebar text chat can be Instant Messaging like and = Interactive text like. Depending on the user = preferences.

Interactive text to IM can be fully transparant. IM to = Interactive text is a bit more complicated due the difference of text delivery (streaming = versus a block of text). If the latter is done, thus IM to Interactive text, = some indicator should be given to the Interactive text user that the text = will come in bursts.

 

Most likely sidebar users start by default in IM mode and when = the IM session becomes more a conversation, both users can deside to switch to Interactive text.

 

Suggested additions in the = conference scenarios draft (draft-ietf-xcon-conference-scenarios-00.txt) in = addition to the above scenarios:

 

3.5 Advanced conference features. (page = 6)

Add:

Changing media anytime during the conference., during the course = of a conference, a participant may be able to choose a different media stream = in addition to the media streams currently present in the conference. For = example, a participant initially joined the conference and discovers that he or = she is unable to understand the language properly. (non native speaker or = hearing impaired). The participant then requests an Interactive text stream with = the same conversation found in the audio stream, same language or an = alternative language (for transcription and/or closed = captions).

It must be possible to invoke a transcoding service in the = conference if the participant requires one. The transcoding service can for example = be speech to text and vice versa as well speech to video signlanguage and = vice versa.

 

Page 7: Change in the fragment describing = sideconference/sidebars (3rd paragraph). Last line, Or an audio or video conference may have a text = sidebar using RFC 2793 Interactive texting OR Instant messaging. Depending on = the preference of the conference participant.

 

4. Scenarios for media policy control (page = 8)

Add: The scenarios apply to audio conference as well as to total conversation conferences where video and interactive text are included = in the conference.

 

4.3 Conference sidebar scenario (page = 10)

 

Add: (2nd paragraph) User invites participants…….

If the new participant uses a transcoded media stream in the = main conference, this media stream must be available in the sidebar if it = belongs to the sidebar selected media. For example when an English audio stream is = moved to the sidebar, the transcoded Spanish text stream must also move to the sidebar. Even if the sidebar creator selected the main conference = English audio stream.

 

Add: (after  the 4th paragraph) Sidebar = participants with the right authorization must be able to use interactive text in = addition to or replacing the audio stream in the sidebar. If desired. Even if the = main conference did not use a transcoded  interactive text = stream.

 

4.7 (page 12), change: last line:

Note that a real-time transcription/closed captioning service = can provide a similar window in which audio media is converted to = text.

Into: Note that a real-time transcription/closed captioning = service can provide a similar window in which audio media is converted into = interactive text.

 

4.9 Text Sidebars (page 12)

 

My advice is to make a = distinction between the 2 forms of text communication. Interactive text and Instant = messaging.

 

Change: ‘Text or instant messaging sidebars’ =

Into: ‘Interactive text or Instant Messaging = sidebars’

 

Change: ‘For example, a conference which is providing = anonymity/

   aliases to participants can also provide = anonymous/alias sidebars.  A

   text sidebar can also benefit from other security/logging/recording

   services provided by the = focus.’

 

Into: For example, ……. provided by the focus. And = another use of a text sidebar is a text only conversation/discussion between 2 = or more conference participants while at the same time following the main = conference without being distracted by additional = audio.

 

 

 

 

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands.
Mobile: +31651921948
International text telephone: +31735588408

 

------=_NextPart_000_002C_01C439D5.83753390-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 14 14:55:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14072 for ; Fri, 14 May 2004 14:55:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhl7-00008q-3E for xcon-archive@odin.ietf.org; Fri, 14 May 2004 14:50:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EIoDOk000540 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 14:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhjb-0008Eu-De for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 14:48:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13290 for ; Fri, 14 May 2004 14:48:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOhjY-00064G-Mb for xcon-web-archive@ietf.org; Fri, 14 May 2004 14:48:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOhhd-0005Kr-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 14:46:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOhen-0004SV-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 14:43:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhaP-0005hA-1m; Fri, 14 May 2004 14:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhVe-0004Z7-Tc for xcon@optimus.ietf.org; Fri, 14 May 2004 14:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11749 for ; Fri, 14 May 2004 14:34:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOhVc-0000Wj-95 for xcon@ietf.org; Fri, 14 May 2004 14:34:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOhUg-00001t-00 for xcon@ietf.org; Fri, 14 May 2004 14:33:15 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BOhTn-0007La-00 for xcon@ietf.org; Fri, 14 May 2004 14:32:19 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EIUlH21565; Fri, 14 May 2004 21:30:47 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 21:30:36 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4EIUagR021355; Fri, 14 May 2004 21:30:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00iVHoTy; Fri, 14 May 2004 21:30:33 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EIUXH21519; Fri, 14 May 2004 21:30:33 +0300 (EET DST) Received: from nokia.com ([10.162.252.165]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 21:30:33 +0300 Message-ID: <40A51046.1020700@nokia.com> Date: Fri, 14 May 2004 21:30:30 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Henning Schulzrinne CC: Ted Hardie , Markus.Isomaki@nokia.com, alex.audu@alcatel.com, alan.johnston@mci.com, xcon@ietf.org, jdrosen@dynamicsoft.com, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: <40A2979E.70101@cs.columbia.edu> <40A3250E.6000604@nokia.com> <40A367AB.8000102@cs.columbia.edu> In-Reply-To: <40A367AB.8000102@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2004 18:30:33.0305 (UTC) FILETIME=[8AD7F490:01C439E1] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Henning, I think this is an interesting idea. But I don't see the difference between this approach, and one where upon first time confirmation the moderator explicitly grants a user an "allow" permission. However, can we conclude that in these scenarios at least, there is anyway a valid requirement for having a condition statement that is for "any" identity? Cheers, Aki ext Henning Schulzrinne wrote: > A random idea: > > make the admission policy stateful and design a special condition that says > > "any URI && if admitted for the first time, then [admit without > confirmation|confirm|..." > > The person kicked out would fail that test and get the special > individualized treatment (such as confirmation required or rejection). > > The drawback is that the higher-layer bouncer application would have to > add the good guys to the explicit user list to make it easier for them > to rejoin if they should leave temporarily, but that's probably > unavoidable anyway if the initial admission requires confirmation. (You > wouldn't want to have to manually approve each person in a large group > each time they come and go.) > > The advantage of tracking admission count is that this also simplifies > the "ask when joining the conference for the first time, get admitted > automatically if rejoining". > > Aki Niemi wrote: > >> >> >> ext Henning Schulzrinne wrote: >> >>>> I guess one question that follows from this is a use case question: >>>> how often will a conference organizer be able to close a conference >>>> *completely* to new participants at some point in the conference? >>>> That would provide a pretty obvious counter to newly minted identities, >>>> but it seems like it might be a small subset of likely cases. Any data >>>> on that? >>> >>> >>> >>> >>> I think this is fairly common - once a conference has been in >>> progress for a while, it's natural to close to door to random >>> strangers. In some cases, I suspect that there will be a human in the >>> loop - "send email to conference-admin@foo.com and we'll add you to >>> the member list". >> >> >> >> Or set true in the authz policy, which >> would mean the moderator gets a notification of someone trying to join >> (using the conference-info events), and can reactively authorize that >> person. >> >> However, this sort of admittance policy is well within the bounds of >> what common-policy already supports. No problem there. >> >>> If you get a person that you have to kick out because they are >>> misbehaving, you might assume that this person has some incentive to >>> re-join and continue his tirades. >> >> >> >> Certainly. Kicking someone off the conference is nothing more than a >> slap on the hand. Kicking and banning someone is a little bit >> stronger, but still not enough to guarantee good riddance of the >> misbehaving individual. >> >> There is certain analogy here with IRC, where both /kick and /kick-ban >> are operations a channel operator can invoke. In IRC coming up with a >> new nick bears close to zero cost, yet both of these operations are >> needed and AFAIK, used in the real world. >> >> I think we need the same features in CPCP since I think text chats are >> also one form of conferencing. >> >>> It seems like that the better model for this is to affect mixing, and >>> simply withdraw the floor from the person. This is needed in any >>> event for the common case where somebody has put their phone on mute, >>> not realizing that this generates music-on-hold (or walked out of the >>> room, leaving the microphone on, which then captures street noise). >>> >>> What cases are there that mixing policy wouldn't have the same effect >>> than explicit removal? >> >> >> >> At least the experience is different for the participant being >> removed. Anyway, I think the requirement for CPCP to be able to expel >> participants is quite clear. I think this is also orthogonal to any >> mixing policy requirements. >> >> Cheers, >> Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri May 14 15:20:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16638 for ; Fri, 14 May 2004 15:20:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOiDA-0007Un-2p for xcon-archive@odin.ietf.org; Fri, 14 May 2004 15:19:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EJJC1C028807 for xcon-archive@odin.ietf.org; Fri, 14 May 2004 15:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOi6a-00058q-A2 for xcon-web-archive@optimus.ietf.org; Fri, 14 May 2004 15:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15677 for ; Fri, 14 May 2004 15:12:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOi6Z-0002Um-4f for xcon-web-archive@ietf.org; Fri, 14 May 2004 15:12:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOi5R-0001yz-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 15:11:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOi4E-000129-00 for xcon-web-archive@ietf.org; Fri, 14 May 2004 15:09:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhyd-0007FX-9P; Fri, 14 May 2004 15:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhwr-0005hj-QF for xcon@optimus.ietf.org; Fri, 14 May 2004 15:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14488 for ; Fri, 14 May 2004 15:02:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOhwo-0005FJ-Sf for xcon@ietf.org; Fri, 14 May 2004 15:02:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOhvw-0004kG-00 for xcon@ietf.org; Fri, 14 May 2004 15:01:24 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BOhv5-0004E0-00 for xcon@ietf.org; Fri, 14 May 2004 15:00:31 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4EJ0Rbt020677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2004 15:00:28 -0400 (EDT) Message-ID: <40A5174B.4020304@cs.columbia.edu> Date: Fri, 14 May 2004 15:00:27 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: xcon@ietf.org Subject: Re: [XCON] Authorization in conference policy References: <40A2979E.70101@cs.columbia.edu> <40A3250E.6000604@nokia.com> <40A367AB.8000102@cs.columbia.edu> <40A51046.1020700@nokia.com> In-Reply-To: <40A51046.1020700@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.14.100776 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think my idea avoids violating the 'positive rules only' design criterion ('no exceptions'), as in alice anytime admit bob firsttime confirm * firsttime confirm trudy anytime deny where Trudy is the person that got kicked out. New arrivals would match the '*' line (and maybe the Alice or Bob rule), and would require confirmation. Trudy, however, would only match the last rule, since she's not a first-timer. Clearly, you can't usefully have * anytime admit trudy anytime deny Aki Niemi wrote: > Hi Henning, > > I think this is an interesting idea. But I don't see the difference > between this approach, and one where upon first time confirmation the > moderator explicitly grants a user an "allow" permission. > > However, can we conclude that in these scenarios at least, there is > anyway a valid requirement for having a condition statement that is for > "any" identity? Yes. One could event extend my mechanism to the IM/presence/call admission case, although I'm not arguing for that. It basically gives everyone one chance before being blacklisted. For conferences, the record is wiped clean at the end of the conference, while for the others, there would have to be some policy stating the statute of limitations for the banning. > > Cheers, > Aki > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon May 17 02:35:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01834 for ; Mon, 17 May 2004 02:35:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbhZ-0007fk-Vc for xcon-archive@odin.ietf.org; Mon, 17 May 2004 02:34:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H6YH8v029493 for xcon-archive@odin.ietf.org; Mon, 17 May 2004 02:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbh4-0007Z8-69 for xcon-web-archive@optimus.ietf.org; Mon, 17 May 2004 02:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01747 for ; Mon, 17 May 2004 02:33:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbh0-0001pV-ET for xcon-web-archive@ietf.org; Mon, 17 May 2004 02:33:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPbg6-0001Xp-00 for xcon-web-archive@ietf.org; Mon, 17 May 2004 02:32:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPbfG-0001GE-00 for xcon-web-archive@ietf.org; Mon, 17 May 2004 02:31:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbbX-0006R9-Dy; Mon, 17 May 2004 02:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbXV-000583-7O for xcon@optimus.ietf.org; Mon, 17 May 2004 02:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01109 for ; Mon, 17 May 2004 02:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbXR-0006YU-H2 for xcon@ietf.org; Mon, 17 May 2004 02:23:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPbWT-0006DP-00 for xcon@ietf.org; Mon, 17 May 2004 02:22:50 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BPbUy-0005ft-00 for xcon@ietf.org; Mon, 17 May 2004 02:21:16 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4H6KUbo002685; Mon, 17 May 2004 02:20:31 -0400 (EDT) Message-ID: <40A8599B.10206@dynamicsoft.com> Date: Mon, 17 May 2004 02:20:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: hardie@qualcomm.com, alex.audu@alcatel.com, alan.johnston@mci.com, aki.niemi@nokia.com, xcon@ietf.org, hgs@cs.columbia.edu, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: In-Reply-To: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_COST autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think its worth taking a step back and seeing what problems are being solved here. Both geopriv and simple are interested in defining authorization policies that are fundamentally related to privacy systems - that is, systems which give out information to individuals, where a user needs to give permission for information to be seen. The strong need for privacy has driven the entire model in common-policy which is based on the concept of privacy safety, whereby, in case of some error, less information is divuldged rather than more. In xcon, we want authorization policies that define who is allowed and not allowed to join a conference. I do not think these constitute privacy systems, and as such, I dont think that privacy safety is a consideration here. As Ted points out, there are some commonalities in probelm space (dealing with the ease with which a user can mint identities), but its still a different problem. In terms of differences, there are many. For example, the notion of transformations in common policy doesnt make a lot of sense in xcon. As such, I dont think it makes sense to directly reuse common policy so much as learn from it and borrow parts of its schema and design where appropriate. -Jonathan R. Markus.Isomaki@nokia.com wrote: > Ted, > > I guess I agree with all what you say below, but I wasn't able to conclude whether you think that > a) common policy should not be used in CPCP > b) common policy could be used but defining all-except for CPCP makes no sense > c) common policy could be used and defining all-except for CPCP might be OK > > (I'm not trying to make a mess with the all-except stuff in all possible cases. I actually like the common policy work a lot, I just think that many conferencing use cases make c) a reasonable approach.) > > Some comments also inline. > > Ted Hardie wrote: > >>At 11:41 PM +0300 05/12/2004, wrote: >> >>>However, I think the conferencing case is still different. There we >>>could not really live without the all-except construct. In >>>conference you don't just protect some data, but you also protect >>>the conference participants from a misbehaving participant. So >>>blocking and kicking out a single identity is important and useful, >>>even if the same person could join later with another identity. >> >>And I think that is the crux of the question. In previous >>discussions, >>the idea that a misbehaving individual could mint an identity at >>essentially no cost meant that creating an "any except" construct >>didn't actually prevent much. > > > Well, I still think that in most cases I have in mind getting a new identity with no cost is not possible, so I would surely have use for all-except in general. But I guess that was discussed separately already. > > >>Your argument seems to say >>that even though it doesn't prevent them from accessing the >>conference, the *act* of kicking them out and blocking them >>has some value in and of itself. >> > > > Obviously not if the participants that are kicked out always appear 1 second later again with a new disguise ;) However, I assume that there still would be non-zero cost for getting the new identity, especially measured in time - so even if the person is persistent it maybe possible for the moderator to do _something_ about him. > > >>Speaking personally, it seems most likely to be valuable only >>in cases where 1) the individual must mint a new identity (i.e. cannot >>easily use a different, existing identity) and 2) this takes >>sufficient >>time that the conference proceeds without disruption either to its >>conclusion or for some significant period of time. I'm not sure about >>the percentage of cases likely to meet both 1 and 2. >> > > > OK, I guess we agree here. I certainly have no exact figures, but I believe, and have seen in chat systems such as IRC, that these conditions are in many cases fulfilled. And what is the alternative? Not being able to do anything in any case (than to close the conference for new entries)? > > >>I guess one question that follows from this is a use case question: >>how often will a conference organizer be able to close a conference >>*completely* to new participants at some point in the conference? >>That would provide a pretty obvious counter to newly minted >>identities, >>but it seems like it might be a small subset of likely cases. >> Any data >>on that? >> regards, >> Ted Hardie >> >> >> > > > Markus > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon May 17 03:12:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03444 for ; Mon, 17 May 2004 03:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcHE-0004Fw-Hm for xcon-archive@odin.ietf.org; Mon, 17 May 2004 03:11:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H7B8oe016347 for xcon-archive@odin.ietf.org; Mon, 17 May 2004 03:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcDy-0003cT-1S for xcon-web-archive@optimus.ietf.org; Mon, 17 May 2004 03:07:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03268 for ; Mon, 17 May 2004 03:07:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcDu-0004Qt-4E for xcon-web-archive@ietf.org; Mon, 17 May 2004 03:07:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcCt-00048i-00 for xcon-web-archive@ietf.org; Mon, 17 May 2004 03:06:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPcC5-0003r3-00 for xcon-web-archive@ietf.org; Mon, 17 May 2004 03:05:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPc5X-0002Wn-JH; Mon, 17 May 2004 02:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPc3S-0002C0-Gr for xcon@optimus.ietf.org; Mon, 17 May 2004 02:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02820 for ; Mon, 17 May 2004 02:56:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPc3O-00010z-Ff for xcon@ietf.org; Mon, 17 May 2004 02:56:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPc2N-0000ie-00 for xcon@ietf.org; Mon, 17 May 2004 02:55:47 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BPc1d-0000QE-00 for xcon@ietf.org; Mon, 17 May 2004 02:55:01 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H6pdk19114; Mon, 17 May 2004 09:51:39 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 09:51:14 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4H6pEeO013339; Mon, 17 May 2004 09:51:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00CijEkf; Mon, 17 May 2004 09:50:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H6orH22179; Mon, 17 May 2004 09:50:53 +0300 (EET DST) Received: from nokia.com ([172.21.81.135]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 09:50:43 +0300 Message-ID: <40A860C2.1000209@nokia.com> Date: Mon, 17 May 2004 09:50:42 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: Markus.Isomaki@nokia.com, hardie@qualcomm.com, alex.audu@alcatel.com, alan.johnston@mci.com, xcon@ietf.org, hgs@cs.columbia.edu, jmorris@cdt.org, Hannes.Tschofenig@siemens.com, Jorge.Cuellar@siemens.com, jmpolk@cisco.com, hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: Re: [XCON] Authorization in conference policy References: <40A8599B.10206@dynamicsoft.com> In-Reply-To: <40A8599B.10206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2004 06:50:43.0913 (UTC) FILETIME=[46747390:01C43BDB] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline. ext Jonathan Rosenberg wrote: > I think its worth taking a step back and seeing what problems are being > solved here. > > Both geopriv and simple are interested in defining authorization > policies that are fundamentally related to privacy systems - that is, > systems which give out information to individuals, where a user needs to > give permission for information to be seen. The strong need for privacy > has driven the entire model in common-policy which is based on the > concept of privacy safety, whereby, in case of some error, less > information is divuldged rather than more. True, and conferencing as such is a different application in that a participant is usually not merely consuming data, but also providing it into a conference. But common policy does also include this mode of operation ("active request-response"). And I would argue that privacy safety in conference authorization is as important as in presence or location. > In xcon, we want authorization policies that define who is allowed and > not allowed to join a conference. I do not think these constitute > privacy systems, and as such, I dont think that privacy safety is a > consideration here. As Ted points out, there are some commonalities in > probelm space (dealing with the ease with which a user can mint > identities), but its still a different problem. I don't think authorization policies in a conference are simply about who is allowed and who is in not allowed to join. In fact, I think this is simply a precursor to "true" geopriv-style rules where privacy-safety is of importance. For example, who can subscribe to conference information events or see floor control events. Who, in addition to seeing the floors, can request/grant them, etc. > In terms of differences, there are many. For example, the notion of > transformations in common policy doesnt make a lot of sense in xcon. This also puzzled me at first, but let me give you an example of what transformations could look like in conferencing: joe@example.com accept true In essence, this would grant joe access to the conference, and tag him as a "key-participant", allowing for example the focus to perform a dial-out. This is very well aligned with common policy, since this particular transformation is also a positive grant of permission - it specifies how the "join" needs to be modified before joe is given access to the conference. It is not about how to modify the information before passing it to joe, simply because that isn't what joe is requesting here. However, were we constructing a rule about whether joe is able to subscribe tio conference-info events, the transformations could be something very similar to e.g. presence authorization. > As such, I dont think it makes sense to directly reuse common policy so > much as learn from it and borrow parts of its schema and design where > appropriate. This is also a good approach. My guess at this point is though, that we would end up with something very closely resembling common-policy anyway. Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue May 18 05:32:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27881 for ; Tue, 18 May 2004 05:32:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0mf-0007OK-R3 for xcon-archive@odin.ietf.org; Tue, 18 May 2004 05:21:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I9LDkN028412 for xcon-archive@odin.ietf.org; Tue, 18 May 2004 05:21:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0ke-0006nt-LY for xcon-web-archive@optimus.ietf.org; Tue, 18 May 2004 05:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27130 for ; Tue, 18 May 2004 05:19:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0kb-0002Sp-D2 for xcon-web-archive@ietf.org; Tue, 18 May 2004 05:19:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0jO-0001xz-00 for xcon-web-archive@ietf.org; Tue, 18 May 2004 05:17:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0iE-0001Bv-00 for xcon-web-archive@ietf.org; Tue, 18 May 2004 05:16:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0Zt-0003xw-TK; Tue, 18 May 2004 05:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0Sw-0002Ak-8S for xcon@optimus.ietf.org; Tue, 18 May 2004 05:00:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25839 for ; Tue, 18 May 2004 05:00:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0Ss-0002L2-Vi for xcon@ietf.org; Tue, 18 May 2004 05:00:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0Rt-0001xZ-00 for xcon@ietf.org; Tue, 18 May 2004 04:59:46 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0Qj-0001Dg-00 for xcon@ietf.org; Tue, 18 May 2004 04:58:38 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4I8wXe19772 for ; Tue, 18 May 2004 11:58:34 +0300 (EET DST) X-Scanned: Tue, 18 May 2004 11:58:28 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4I8wSEE030887 for ; Tue, 18 May 2004 11:58:28 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00ni3h3o; Tue, 18 May 2004 11:58:27 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4I8wRH13159 for ; Tue, 18 May 2004 11:58:27 +0300 (EET DST) Received: from nokia.com ([172.21.81.135]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 May 2004 11:58:27 +0300 Message-ID: <40A9D032.50404@nokia.com> Date: Tue, 18 May 2004 11:58:26 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: XCON WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2004 08:58:27.0298 (UTC) FILETIME=[4899F420:01C43CB6] Content-Transfer-Encoding: 7bit Subject: [XCON] New draft for conference authorization rules based on common policy 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, I've written a draft that proposes conference authorization based on the common policy framework. It's not a counter-proposal to the ongoing CPCP work as such, as it only talks about authorization as in conference participation and conference state and floor control events. If we were to conclude that this approach is preferable to what currently exists in CPCP, the contents of this draft would need to be merged with the CPCP draft. Comments are welcome. Until the draft appears at the directories, I've placed a copy at: http://people.nokia.net/~aki/drafts/draft-niemi-xcon-cpcp-rules-00.txt http://people.nokia.net/~aki/drafts/draft-niemi-xcon-cpcp-rules-00.html Cheers, Aki _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:52:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01328 for ; Thu, 20 May 2004 12:52:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqWx-0002Kw-9A for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:36:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGaRQ1008982 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqCv-0003v1-Tk for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28814 for ; Thu, 20 May 2004 12:15:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqCu-0002LN-Kg for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:15:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqBu-0002F0-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:14:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqAz-00027Y-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:13:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpvl-0004oo-5P; Thu, 20 May 2004 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpe7-0006Zj-PH for xcon@optimus.ietf.org; Thu, 20 May 2004 11:39:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25000 for ; Thu, 20 May 2004 11:39:44 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpe6-0005Zf-JP for xcon@ietf.org; Thu, 20 May 2004 11:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpd5-0005Sr-00 for xcon@ietf.org; Thu, 20 May 2004 11:38:44 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQpcB-0005MJ-00 for xcon@ietf.org; Thu, 20 May 2004 11:37:52 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFbgL18380 for ; Thu, 20 May 2004 18:37:42 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:37:41 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFbfWv018976 for ; Thu, 20 May 2004 18:37:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00e6Rgpc; Thu, 20 May 2004 18:37:40 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFbeH04587 for ; Thu, 20 May 2004 18:37:40 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:37:39 +0300 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 May 2004 18:37:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B3F@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 1: External Lists in CPCP Thread-Index: AcQ+gGH7gxrCqrc7TD2Hh4kVAxjWng== To: X-OriginalArrivalTime: 20 May 2004 15:37:39.0902 (UTC) FILETIME=[624AC5E0:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 1: External Lists in CPCP 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There has been suggestions that external lists can be placed as a = resource in the conference policy dial-out list or dial-in list. In the dial-out case, the external list (or its participants, to be more = accurate) can be invited into the conference by the focus in 2 ways: 1. The creator of the conference places the XCAP URI for the external = list URI (assuming that the list was created using the XCAP list usage) = into Dial-out list. When it is time for the focus to invite users into = the conference, the focus uses the XCAP list URI to fetch the URIs for = the members of the external list. It then sends INVITE (in SIP terms) to = the members of that external list. This results in all participants = connected to one focus. 2. The creator of the conference places the SIP URI of the external list = into the Dial-out list. When it is time for the focus to invite users = into the conference, the focus sends INVITE to the all the members of = that dial-out list, including an INVITE to the external list. This = INVITE may result in another cascaded conference being created. Which scenario is more appealing to people. The 3rd option of course is = to disable this feature. In the dial-in case, 2 ways are also possible: 1. The XCAP URI for the external list is placed. This enables the focus = to fetch the member URIs in order to determine if a user is allowed to = participate in a conference or not. 2. The SIP URI for the external list is placed. The focus then only = accepts participation from the group (they could create a separate = conference and try to cascade it into this conference). Again, the 3rd option here is to disable this feature. I am leaning towards option 1 in both cases. But this introduces another = complexity: What if the external list membership changes? Should the = focus react in any way. My proposal for an answer to this problem is no, = the focus does not react in any way. The focus only deals with the copy = it fetched. This copy is not persistent. I.e. If a second conference = occurrence happens, the focus will be required to fetch a copy of the = external list again. Comments? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:52:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01344 for ; Thu, 20 May 2004 12:52:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqXE-0002bp-VN for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:36:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGaisG010022 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:36:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqET-0004b8-5P for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:17:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28909 for ; Thu, 20 May 2004 12:17:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqER-0002Uy-R6 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:17:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqDY-0002P1-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:16:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqCU-0002JM-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:15:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqCV-00010V-ED for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:15:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpvp-0004va-58; Thu, 20 May 2004 11:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpfe-0007bx-W8 for xcon@optimus.ietf.org; Thu, 20 May 2004 11:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25071 for ; Thu, 20 May 2004 11:41:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpfd-0005qE-PC for xcon@ietf.org; Thu, 20 May 2004 11:41:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpe0-0005Yc-00 for xcon@ietf.org; Thu, 20 May 2004 11:39:40 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQpd4-0005SG-00 for xcon@ietf.org; Thu, 20 May 2004 11:38:42 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFceL19225 for ; Thu, 20 May 2004 18:38:40 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:38:28 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4KFcSh8004753 for ; Thu, 20 May 2004 18:38:28 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Ok6ptG; Thu, 20 May 2004 18:38:17 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFcHH12802 for ; Thu, 20 May 2004 18:38:17 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:38:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:38:17 +0300 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 May 2004 18:38:17 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B40@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 2: Namespaces Thread-Index: AcQ+gHf4oXnOrBW3QmGUl7/ABzlY/A== To: X-OriginalArrivalTime: 20 May 2004 15:38:17.0226 (UTC) FILETIME=[7889F6A0:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 2: Namespaces 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We envisioned that privileges will be assigned to users according to the = schema. So, if I want to give you permission to add people to the = dial-out list, then in effect I am giving you write permission to that = part of the XML document. We therefore divided the XML schema into = multiple schemas where each part can be viewed as a privilege. We also = envisioned that a second XCAP usage document will be created containing = the privileges gives to participants (and others) of the conference. 3 = pieces of information: URI of the XCAP document that privileges are = being given for, the users that are being granted privileges, and the = namespaces that those users can manipulate elements in (the privilege). We now think it can be done using XPATH and therefore will remove the = multiple namespaces. Multiple namespaces makes the XML document too = confusing. I propose removing the multiple namespaces and collapsing the whole XML = definition for CPCP into one namespace. Comments? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:53:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01500 for ; Thu, 20 May 2004 12:53:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqXj-0002iM-IJ for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGbFcd010429 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqGv-0005Do-O7 for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:19:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29081 for ; Thu, 20 May 2004 12:19:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqGu-0002k9-DV for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqGK-0002gu-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:19:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqFi-0002cX-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:18:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpvz-00051I-7V; Thu, 20 May 2004 11:58:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpgI-0007r9-Ih for xcon@optimus.ietf.org; Thu, 20 May 2004 11:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25194 for ; Thu, 20 May 2004 11:41:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpgH-0005xD-Bn for xcon@ietf.org; Thu, 20 May 2004 11:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpeb-0005f2-00 for xcon@ietf.org; Thu, 20 May 2004 11:40:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQpdc-0005Wr-00 for xcon@ietf.org; Thu, 20 May 2004 11:39:17 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFdCe00824 for ; Thu, 20 May 2004 18:39:12 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:39:06 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4KFd62p006149 for ; Thu, 20 May 2004 18:39:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00wU0Qmk; Thu, 20 May 2004 18:39:04 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFd4H13117 for ; Thu, 20 May 2004 18:39:04 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:39:03 +0300 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 May 2004 18:39:04 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B41@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 3: Wildcards in ACL Thread-Index: AcQ+gJPa8ST9Ifk7QDqac7CIs6t49A== To: X-OriginalArrivalTime: 20 May 2004 15:39:03.0527 (UTC) FILETIME=[9422EF70:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 3: Wildcards in ACL 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The current version of the draft states: "Wildcards are allowed in ACL as follows. The domain part is allowed to be wildcard only if the username is a wildcard. Wildcard in the domain part MUST be immediately after the @-sign. A wildcard in the domain is interpreted as multiple zones. For example: sip:*@*.example.com includes sip:*@engineering.example.com as well as sip:*@tester.engineering.example.com. The use of wildcarding has been restricted to avoid ambiguous entries in the access control list. Examples of allowed wildcards are - sip:*@example.com, *@*.com, *@*. Examples are not allowed wildcards are - sip:bob@example.*, sip:bob@*.com, sip:*@example.*.com." It has occurred to me that instead of wildcarding entries in the ACL, a = domain can be entered instead, so instead of: sip:*@example.com We can have: sip:example.com It's a little trickier to indicate all domains. Currently, it is defined = to look like this: *@* sip:*@* The question is: How to indicate that? Proposal 1: allow the URI entry to be * as follows (* is a valid URI = character) * Proposal 2: have a Marco ANYURI be defined. ANYURI I prefer 1 in this case, but would welcome other ideas. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:55:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01655 for ; Thu, 20 May 2004 12:55:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqex-0004cD-3K for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:44:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGih4V017736 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqTk-0000b5-H9 for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29719 for ; Thu, 20 May 2004 12:33:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqTj-0003dM-26 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqSe-0003Wt-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:01 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqRl-0003SK-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqRm-0003nU-Vm for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpzF-0006Kt-Ma; Thu, 20 May 2004 12:01:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQphz-0000bn-GO for xcon@optimus.ietf.org; Thu, 20 May 2004 11:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25399 for ; Thu, 20 May 2004 11:43:44 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQphy-0006BS-CK for xcon@ietf.org; Thu, 20 May 2004 11:43:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpg0-0005up-00 for xcon@ietf.org; Thu, 20 May 2004 11:41:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BQpeL-0005bT-00 for xcon@ietf.org; Thu, 20 May 2004 11:40:01 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFdtF28393 for ; Thu, 20 May 2004 18:39:55 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:39:47 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFdllw023671 for ; Thu, 20 May 2004 18:39:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00SEKIut; Thu, 20 May 2004 18:39:46 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFdeH05982 for ; Thu, 20 May 2004 18:39:40 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:39:40 +0300 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 May 2004 18:39:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B42@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 4: refer Thread-Index: AcQ+gKmxW2YhTSvNSP24DeWlFEJLZw== To: X-OriginalArrivalTime: 20 May 2004 15:39:40.0152 (UTC) FILETIME=[A9F77780:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 4: refer 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Chris brought this up already in a separate thread. Currently, it is possible to ask the focus to refer users to the = conference. An optional Boolean attribute "refer" exists in the = that indicates to the server that the creator of the = conference wishes for the focus to refer the identified potential = participants to the conference when a conference occurrence has started. = In SIP, this is achieved by the focus sending a REFER request to those = potential participants. Some people commented that this really belongs to the Dial-out list. My = view is that it belongs to the ACL for the following reasons: - The focus is not really dialling out to the users, but merely = referring them. DL tells the focus to dial-out. I.e. create a session = with the participant. - The users then dial in and therefore an entry in the ACL is needed = anyway to give them permission to dial in. If we place the refer in the = DL, then we need 2 entries for every referred participant. One in DL and = the other in ACL. That makes modifying the conference policy a little = more difficult. I prefer to keep it in the ACL. I would like to get other people's view = on this. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:55:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01694 for ; Thu, 20 May 2004 12:55:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqfv-0004pk-IZ for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:45:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGjhiq018576 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqTn-0000bK-JB for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29730 for ; Thu, 20 May 2004 12:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqTl-0003de-Qv for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqSg-0003XC-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqRx-0003SS-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:17 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqRy-0003pv-UH for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpzH-0006MD-77; Thu, 20 May 2004 12:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpiR-0000fb-A6 for xcon@optimus.ietf.org; Thu, 20 May 2004 11:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25448 for ; Thu, 20 May 2004 11:44:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpiQ-0006Eg-5f for xcon@ietf.org; Thu, 20 May 2004 11:44:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpgY-0005z7-00 for xcon@ietf.org; Thu, 20 May 2004 11:42:19 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQpem-0005gv-00 for xcon@ietf.org; Thu, 20 May 2004 11:40:28 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFeRL21111 for ; Thu, 20 May 2004 18:40:27 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:40:21 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFeL6O025049 for ; Thu, 20 May 2004 18:40:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00oGO5QT; Thu, 20 May 2004 18:40:19 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFeHH06438 for ; Thu, 20 May 2004 18:40:17 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:40:14 +0300 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 May 2004 18:40:14 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B44@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 6: conference URI conflict Thread-Index: AcQ+gL3eIGf0ksDhR2WZawnjKW+cOw== To: X-OriginalArrivalTime: 20 May 2004 15:40:14.0249 (UTC) FILETIME=[BE4A4190:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 6: conference URI conflict 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Conference URIs can be proposed by the creator of the conference policy. = If the creator has proposed a conference URI, the server needs to decide = whether it accept the name proposed by the client or not. It does this = determination by examining if the conference URI already exists or not. = Currently, it is not defined how the CPS would react. The obvious answer = is that is returns an error using the protocol that is used to place the = rule on the server. In XCAP, this means sending a 409 error response to the PUT detailing = what went wrong. Since the document defines the behaviour of XCAP as a = possible protocol to carry and manipulate conference policies, the 409 = error response will be used. Any objections? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:55:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01695 for ; Thu, 20 May 2004 12:55:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqfv-0004py-LB for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:45:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGjhkW018589 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqTp-0000bW-KO for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29742 for ; Thu, 20 May 2004 12:33:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqTn-0003dw-O6 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqSh-0003XK-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqS8-0003Sc-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:28 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqS9-0003ro-LL for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpzc-0006TR-VE; Thu, 20 May 2004 12:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpip-0000js-Gz for xcon@optimus.ietf.org; Thu, 20 May 2004 11:44:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25485 for ; Thu, 20 May 2004 11:44:36 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpio-0006Ib-5x for xcon@ietf.org; Thu, 20 May 2004 11:44:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpgx-00063c-00 for xcon@ietf.org; Thu, 20 May 2004 11:42:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQpfA-0005lc-00 for xcon@ietf.org; Thu, 20 May 2004 11:40:52 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFele02274 for ; Thu, 20 May 2004 18:40:48 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:40:44 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFeiDs026095 for ; Thu, 20 May 2004 18:40:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 0055JHTZ; Thu, 20 May 2004 18:40:44 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFeYH06694 for ; Thu, 20 May 2004 18:40:34 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:40:33 +0300 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 May 2004 18:40:34 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B45@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 7: Conference URIs assignment Thread-Index: AcQ+gMmu2kbtGVT8S3qu6h66nUkKHg== To: X-OriginalArrivalTime: 20 May 2004 15:40:33.0921 (UTC) FILETIME=[CA03F710:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 7: Conference URIs assignment 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Currently the ID says that the conference policy server must fill the = conference URI(s), if a conference URI was not proposed by the client. This problem is similar to that on the XCAP List usage where the XCAP = server needs to fill in the list URI if the user did not suggest one. = There is an ongoing discussion on the SIMPLE mailing list about a = proposal where the server does not actually create a URI, but merely = rejects the PUT request with a 409. The body of the 409 response would = carry a list of suggested URIs. This looks like a solid proposal that = will be adopted. We can do a similar thing here for conference URIs. This leaves one open = issue: Since a conference server may support, along with SIP, multiple = session signalling protocols, does the server still create and populate = the conference policy with additional URIs reflecting all the signalling = protocols it supports that were not suggested by the creator? My proposal is for the conference policy server to do so since the = creator does not have the knowledge to know what signalling protocols a = server supports in order to create a full list of URIs. Comments? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:55:34 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01733 for ; Thu, 20 May 2004 12:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqfv-0004qI-Sd for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:45:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGjhaV018608 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqTq-0000ba-Oh for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29748 for ; Thu, 20 May 2004 12:33:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqTp-0003e6-1V for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqSi-0003Xb-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqSI-0003Sk-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:38 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqSK-0003tv-8W for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpzd-0006Tk-UN; Thu, 20 May 2004 12:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpk0-00010y-2o for xcon@optimus.ietf.org; Thu, 20 May 2004 11:45:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25629 for ; Thu, 20 May 2004 11:45:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpjy-0006RD-Uj for xcon@ietf.org; Thu, 20 May 2004 11:45:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpi7-0006Cu-00 for xcon@ietf.org; Thu, 20 May 2004 11:43:56 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQpgK-0005xd-00 for xcon@ietf.org; Thu, 20 May 2004 11:42:04 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFg3L22505 for ; Thu, 20 May 2004 18:42:03 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:42:02 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFg28q029183 for ; Thu, 20 May 2004 18:42:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 000PiQLe; Thu, 20 May 2004 18:42:01 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFftH07528 for ; Thu, 20 May 2004 18:41:55 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:41:49 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:41:49 +0300 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 May 2004 18:41:49 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B47@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 9: Separate XML manipulation text from XCAP text Thread-Index: AcQ+gPZtg8zG/uB7RYq9MhBJ1cftxA== To: X-OriginalArrivalTime: 20 May 2004 15:41:49.0528 (UTC) FILETIME=[F714AD80:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 9: Separate XML manipulation text from XCAP text 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Currently, the draft separates XML schema from XCAP. There was a = suggestion that the XCAP section needs to be reduced again to a very = small section just defining the required sections for an XCAP usage = document. A separate section can then be introduced discussing how = certain scenarios can be achieved (eg: adding a user to the conference) = and what conference policy XML document manipulations are needed for = such scenarios. This section also discusses how a focus reacts when a = policy change was made. If there are no objections, I will make that change. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:55:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01758 for ; Thu, 20 May 2004 12:55:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqhg-0005G1-Ey for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:47:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGlWwa020203 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqUc-0001CG-To for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:34:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29789 for ; Thu, 20 May 2004 12:33:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqUb-0003kb-C2 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:34:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqTb-0003cL-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqSX-0003Vd-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:53 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqSZ-0003we-52 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpze-0006Tt-BW; Thu, 20 May 2004 12:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpkI-00014E-Ch for xcon@optimus.ietf.org; Thu, 20 May 2004 11:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25653 for ; Thu, 20 May 2004 11:46:07 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpkH-0006UN-84 for xcon@ietf.org; Thu, 20 May 2004 11:46:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpiP-0006EY-00 for xcon@ietf.org; Thu, 20 May 2004 11:44:13 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQpgX-0005yx-00 for xcon@ietf.org; Thu, 20 May 2004 11:42:17 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFgCe03806 for ; Thu, 20 May 2004 18:42:12 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:42:10 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFgAAJ029562 for ; Thu, 20 May 2004 18:42:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00pNOh9l; Thu, 20 May 2004 18:42:09 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFg8H07694 for ; Thu, 20 May 2004 18:42:08 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:42:07 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:42:08 +0300 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 May 2004 18:42:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B48@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 10: focus and XCAP server, how do they interact Thread-Index: AcQ+gQGSbnUOgRYKRFCDmuSlFQ/myw== To: X-OriginalArrivalTime: 20 May 2004 15:42:08.0232 (UTC) FILETIME=[023AAE80:01C43E81] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 10: focus and XCAP server, how do they interact 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The current version of the draft does not discuss at all how the focus = and the conference policy server communicate. There are 2 proposals: 1. Mention that it is out of scope of this document 2. Mention that it is out of scope of this document but, a focus can use = the XCAP (or config) event package. I believe this event package can be = used regardless whether you use XCAP to manipulate the XML document or = not. I have no strong feeling about either. Any better suggestions? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:55:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01816 for ; Thu, 20 May 2004 12:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqkq-00067M-6R for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:50:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGomLd023508 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqUo-0001Fm-GN for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:34:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29809 for ; Thu, 20 May 2004 12:34:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqUm-0003mE-Tf for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:34:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqTq-0003eJ-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqSn-0003Xl-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:09 -0400 Received: from datatracker.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqSo-0003yY-BM for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpzh-0006Uc-3p; Thu, 20 May 2004 12:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpkr-0001AW-LI for xcon@optimus.ietf.org; Thu, 20 May 2004 11:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25713 for ; Thu, 20 May 2004 11:46:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpkq-0006bS-GN for xcon@ietf.org; Thu, 20 May 2004 11:46:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpiq-0006J1-00 for xcon@ietf.org; Thu, 20 May 2004 11:44:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQph0-00063v-00 for xcon@ietf.org; Thu, 20 May 2004 11:42:46 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFgje04621 for ; Thu, 20 May 2004 18:42:45 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:42:31 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFgV1b030315 for ; Thu, 20 May 2004 18:42:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00G0BO1F; Thu, 20 May 2004 18:42:31 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFgPH07912 for ; Thu, 20 May 2004 18:42:25 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:42:25 +0300 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 May 2004 18:42:25 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B49@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 11: Relating a sidebar to a conference Thread-Index: AcQ+gQvrCKqzH9BaRIO/bHtevEFM6g== To: X-OriginalArrivalTime: 20 May 2004 15:42:25.0127 (UTC) FILETIME=[0C4CA770:01C43E81] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 11: Relating a sidebar to a conference 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There are some requirements for sidebars. An example requirement is that = the audio is the main conference can appear in the sidebar in the = background with a lower volume than the conversation that is taking = place in the sidebar. Another requirement is that only the current = participants in the main conference can join or be invited into a side = bar. A sidebar is thought of as a separate conference with it's own = conference URI. In order to satisfy the requirements, the following is = an idea for creating a side bar using conference policy: - A user creating a sidebar must include the main conference as a = participant. This is achieved by adding the main conference URI to the = dial-out list or to the list of potential participants to be referred. - The sidebar focus then either dials out (invites) the main conference = into the side bar or refers it. - The media policy that is part of the conference policy indicates that = the main conference audio, for example, has a lower volume than the rest = of the participants - The main conference focus learns that there is a sidebar to it because = it was invited to join the sidebar (another conference) - The focus of the main conference MUST only accept invitations (or = refers) to join a sidebar after it has examined the sidebar's = participants' lists (DL, ACL) and concluded that all sidebar = participants and creator are in fact participants of the main = conference. It can also learn the sidebar's participant list by = subscribing to the conference state event package Some sidebars are created in an ad hoc manner. I.e. a conference policy = is not created. In this case creating a sidebar is performed as follows: - A user creating a sidebar must refer or invite users to join the side = bar, using SIP or other protocol means - That user then refers the main conference to the sidebar is includes = the main conference in the invitations that it sent to participants to = join the sidebar - The main conference focus learns that there is a sidebar to it because = it was invited to join the sidebar (another conference) - The focus of the main conference MUST only accept invitations (or = refers) to join a sidebar after it has examined the sidebar's = participants' lists and concluded that all sidebar participants and = creator are in fact participants of the main conference. It can do that = by subscribing the conference state event package Comments or other ideas? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:56:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01866 for ; Thu, 20 May 2004 12:56:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqkq-00067e-CR for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:50:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGomi6023526 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqUr-0001Fu-4I for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29815 for ; Thu, 20 May 2004 12:34:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqUp-0003ma-J7 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:34:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqTs-0003eZ-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqSp-0003Xs-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:11 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqSr-00040i-9L for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpzh-0006Um-Hm; Thu, 20 May 2004 12:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpkz-0001B4-Nd for xcon@optimus.ietf.org; Thu, 20 May 2004 11:46:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25721 for ; Thu, 20 May 2004 11:46:50 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpky-0006cn-I1 for xcon@ietf.org; Thu, 20 May 2004 11:46:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpiv-0006Jw-00 for xcon@ietf.org; Thu, 20 May 2004 11:44:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQph8-00064D-00 for xcon@ietf.org; Thu, 20 May 2004 11:42:54 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFgje04626 for ; Thu, 20 May 2004 18:42:45 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:42:39 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFgdiJ030595 for ; Thu, 20 May 2004 18:42:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00yJpCXa; Thu, 20 May 2004 18:42:37 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFgaH08052 for ; Thu, 20 May 2004 18:42:36 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:42:36 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:42:36 +0300 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 May 2004 18:42:36 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B4A@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 12: Media policy vs. Media streams Thread-Index: AcQ+gRKSI2dfdqh/T3+2/Bj1FhwcYQ== To: X-OriginalArrivalTime: 20 May 2004 15:42:36.0810 (UTC) FILETIME=[134356A0:01C43E81] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 12: Media policy vs. Media streams 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This document defines a very basic media policy that states the media = types a conference has. This is used by the focus to know what media = types to invite users with and what media types it should accept from = dialling in users. This is not really media policy. It just defines the media streams that = a conference offers or should offer. I propose a change in the XML schema where is = changed to . Media policy itself can be added later with a separate namespace if we = feel that it belongs in CPCP. If there are no objections, I'll make that change. Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 12:58:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02056 for ; Thu, 20 May 2004 12:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqnx-000757-Ot for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:54:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGs1NF027216 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqYg-00034j-IU for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00264 for ; Thu, 20 May 2004 12:38:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqYe-0004CY-UU for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:38:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqXe-00045j-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:37:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqWw-0003ys-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:36:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqDC-0004EC-E0; Thu, 20 May 2004 12:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpvm-0004uy-Bl for xcon@optimus.ietf.org; Thu, 20 May 2004 11:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27103 for ; Thu, 20 May 2004 11:57:59 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpvl-0000IQ-3d for xcon@ietf.org; Thu, 20 May 2004 11:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpuu-0000Cv-00 for xcon@ietf.org; Thu, 20 May 2004 11:57:08 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQpu2-00008k-00 for xcon@ietf.org; Thu, 20 May 2004 11:56:14 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFuCe17832 for ; Thu, 20 May 2004 18:56:13 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:56:12 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4KFuC9x019883 for ; Thu, 20 May 2004 18:56:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00m74pEu; Thu, 20 May 2004 18:56:07 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFe4H06264 for ; Thu, 20 May 2004 18:40:04 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:40:02 +0300 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 May 2004 18:40:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B43@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 5: Conflicting rules in ACL Thread-Index: AcQ+gLb5LFaSy9e/T26EbEbDaPnltA== To: X-OriginalArrivalTime: 20 May 2004 15:40:02.0893 (UTC) FILETIME=[B78577D0:01C43E80] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 5: Conflicting rules in ACL 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It is possible that a user creates conflicting rules in an ACL. = Conflicting rules MUST NOT exist (e.g. both allowed and blocked action = is defined for same target). It is the responsibly of the conference = policy server (CPS) to ensure such conflicts do not occur. Currently, it is not defined how the CPS would react. The obvious answer = is that is returns an error using the protocol that is used to place the = rule on the server. In XCAP, this means sending a 409 error response to the PUT detailing = what went wrong. Since the document defines the behaviour of XCAP as a = possible protocol to carry and manipulate conference policies, the 409 = error response will be used. Any objections? Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 13:10:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02868 for ; Thu, 20 May 2004 13:10:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqpj-0001qq-9P for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:55:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGtprY007111 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqlL-0006Ay-6L for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:51:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01101 for ; Thu, 20 May 2004 12:51:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqlJ-0005KY-Eg for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:51:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqja-00053f-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:49:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqhz-0004sV-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:47:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqU1-0004Fm-33 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:33:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQq4S-0008Fx-T0; Thu, 20 May 2004 12:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpmC-0001n9-QA for xcon@optimus.ietf.org; Thu, 20 May 2004 11:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26009 for ; Thu, 20 May 2004 11:48:05 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpmB-0006u3-MO for xcon@ietf.org; Thu, 20 May 2004 11:48:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpkS-0006WT-00 for xcon@ietf.org; Thu, 20 May 2004 11:46:21 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BQpia-0006Fu-00 for xcon@ietf.org; Thu, 20 May 2004 11:44:24 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFiNC01983 for ; Thu, 20 May 2004 18:44:23 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:44:17 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFiHqa001321 for ; Thu, 20 May 2004 18:44:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00v8yusJ; Thu, 20 May 2004 18:44:16 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFiGH09006 for ; Thu, 20 May 2004 18:44:16 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:44:15 +0300 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 May 2004 18:44:15 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B4D@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 15: Start/Stop times Thread-Index: AcQ+gU1xZ5e07fBNRhq1er33V34wKg== To: X-OriginalArrivalTime: 20 May 2004 15:44:15.0035 (UTC) FILETIME=[4DCF48B0:01C43E81] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 15: Start/Stop times 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Currently conference start time and stop time can only be represented as = follows and do not satisfy the recently agreed requirements: 2003-06-16T10:00:00Z 2003-06-16T12:00:00Z In order to satisfy the requirements, the following is proposed: - REQ-A9: It MUST be possible to define the time when media mixing may start ("don't-mix-before-time") and stop ("cannot-continue-after") operating in the conference. Change and to and = - REQ-A10: It MUST be possible to define the time after which users = are allowed to join the conference. Introduce element - REQ-A11: It MUST be possible to define the time after which new = users are not allowed to join the conference anymore. Introduce element - REQ-A12: It MUST be possible to define the time when users or resources on the dial-out list are invited to join the conference. Introduce elements - REQ-A13: It MUST be possible define whether the conference can be extended. Note: This does not guarantee that resources are available. This can be achieved by documenting that can be = changed to later time - REQ-A15a: It MUST be possible to define when media mixing starts based on the latter of the mixing start time, and the time the first participant arrives. REQ X15b: It MUST be possible to define when media mixing starts based on the latter of the mixing start time, and the time the first key participant arrives. Introduce attribute 'require-participant' in with = values "key-participant" and "participant". - REQ-A16a: It MUST be possible to define when media mixing stops = based on the earlier of the mixing stop time, and the time the last participant leaves the conference. REQ-A16b: It MUST be possible to define when media mixing stops based on the earlier of the mixing stop time, and the time the last key participant leaves. REQ-A16c: It MUST be possible to define when media mixing stops based on the time only. Introduce attribute 'require-participant' in with = values "key-participant" and "participant". - REQ-A17: It MUST be possible to define that the users and resources on the dial-out list are invited only after first key participant has joined. Introduce attribute 'require-participant' in with values = "key-participant" and "participant". An example: 2003-06-16T10:00:00Z= 2003-06-16T12:00:00Z 2003-06-16T09:55:00Z 2003-06-16T10:30:00Z 2003-06-16T09:55:00Z Regards, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 13:10:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02887 for ; Thu, 20 May 2004 13:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqpj-0001rX-Pr for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:55:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGtpMm007151 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqlP-0006BA-3S for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:51:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01119 for ; Thu, 20 May 2004 12:51:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqlN-0005LP-BS for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqjh-00054a-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:49:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqi0-0004sV-02 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:47:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqTV-00049i-I9 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQq3Y-0007iw-14; Thu, 20 May 2004 12:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQplQ-0001NE-Vh for xcon@optimus.ietf.org; Thu, 20 May 2004 11:47:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25788 for ; Thu, 20 May 2004 11:47:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQplP-0006ip-QX for xcon@ietf.org; Thu, 20 May 2004 11:47:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpjH-0006Nt-00 for xcon@ietf.org; Thu, 20 May 2004 11:45:08 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BQphq-00069f-00 for xcon@ietf.org; Thu, 20 May 2004 11:43:38 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFhbC01267 for ; Thu, 20 May 2004 18:43:37 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:43:35 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFhZh9032346 for ; Thu, 20 May 2004 18:43:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00jSSOvU; Thu, 20 May 2004 18:43:33 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFhXH08524 for ; Thu, 20 May 2004 18:43:33 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:43:32 +0300 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 May 2004 18:43:33 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B4C@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 14: Key Participants Thread-Index: AcQ+gTRF5b4isl/AS/+VFXAoQhUy5A== To: X-OriginalArrivalTime: 20 May 2004 15:43:32.0902 (UTC) FILETIME=[34B24C60:01C43E81] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 14: Key Participants 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I was agreed in the last IETF meeting that we need the concept of key = participants in a conference policy. One of the reasons is that a = conference focus would not start mixing media unless one key participant = joins. The open issue here is how to represent the key participants in the XML = document. There are 3 options. 1. In the ACL or DL, we introduce an attribute named 'role' with values = "key-participant", "participant". The attribute would be optional and = has default value of "participant" if not present. 2. In the ACL or DL, we introduce a Boolean attribute name = 'key-participant'. 3. Have a separate list. This disadvantage here is that whenever a new = key participant is added to the conference, 2 changes are needed to the = conference policy in 2 different places. This might be possible with one = XCAP PUT, if the proposed addition is made to XCAP. Comments? Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu May 20 13:10:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02908 for ; Thu, 20 May 2004 13:10:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqpk-0001sK-Ff for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:55:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGtqqW007203 for xcon-archive@odin.ietf.org; Thu, 20 May 2004 12:55:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqlT-0006BR-1y for xcon-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:51:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01143 for ; Thu, 20 May 2004 12:51:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqlR-0005M4-EQ for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:51:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqjq-00056I-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:49:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqi1-0004so-00 for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:47:53 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQqTK-00047e-Dw for xcon-web-archive@ietf.org; Thu, 20 May 2004 12:32:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQq3V-0007iU-U3; Thu, 20 May 2004 12:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQplC-0001Gz-8Q for xcon@optimus.ietf.org; Thu, 20 May 2004 11:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25766 for ; Thu, 20 May 2004 11:47:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQplB-0006fa-3b for xcon@ietf.org; Thu, 20 May 2004 11:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpj7-0006M8-00 for xcon@ietf.org; Thu, 20 May 2004 11:44:58 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BQphS-00067m-00 for xcon@ietf.org; Thu, 20 May 2004 11:43:14 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFhDL23458 for ; Thu, 20 May 2004 18:43:13 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 18:43:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4KFh4rQ031317 for ; Thu, 20 May 2004 18:43:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00m8g7QJ; Thu, 20 May 2004 18:43:01 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KFh1H08253 for ; Thu, 20 May 2004 18:43:01 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 20 May 2004 18:43:00 +0300 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 May 2004 18:43:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B4B@esebe019.ntc.nokia.com> Thread-Topic: CPCP issue 13: floor control policy Thread-Index: AcQ+gSExLvTyeX/iSoSxidRtbR4ixA== To: X-OriginalArrivalTime: 20 May 2004 15:43:00.0790 (UTC) FILETIME=[218E6560:01C43E81] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP issue 13: floor control policy 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is not really an open issue, but I wanted to bring your attention = to what is currently defined for the floor control policy and to see if = there is anything missing. The currently defined satisfies all = requirements in CPCP-reqs draft. Currently defined: "This element has its own XML namespace. The absence of this namespace and its elements from an XML document indicates that the conference does not have a floor. The is mandatory and contains the required boolean attribute that indicates if the floor is moderator controlled or not. One or more elements can appear in the element. The number of those elements indicates how many floors the conference can have. A floor can be used for one or more media types; the mandatory element can contain zero or more of the