From exim@www1.ietf.org Thu Apr 1 07:11:30 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 HAA07963 for ; Thu, 1 Apr 2004 07:11:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B912H-0004zK-9h for xcon-archive@odin.ietf.org; Thu, 01 Apr 2004 07:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CB5SS019174 for xcon-archive@odin.ietf.org; Thu, 1 Apr 2004 07:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B912H-0004zB-59 for xcon-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:11:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07942 for ; Thu, 1 Apr 2004 07:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B912C-000230-00 for xcon-web-archive@ietf.org; Thu, 01 Apr 2004 07:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B911C-0001uN-00 for xcon-web-archive@ietf.org; Thu, 01 Apr 2004 07:09:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B910D-0001o3-00 for xcon-web-archive@ietf.org; Thu, 01 Apr 2004 07:08:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B910G-0004O7-Uz; Thu, 01 Apr 2004 07:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90zc-0004N6-Br for xcon@optimus.ietf.org; Thu, 01 Apr 2004 07:08:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07870 for ; Thu, 1 Apr 2004 07:08:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90zY-0001lW-00 for xcon@ietf.org; Thu, 01 Apr 2004 07:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90yn-0001eH-00 for xcon@ietf.org; Thu, 01 Apr 2004 07:07:30 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B90xg-0001Wq-00 for xcon@ietf.org; Thu, 01 Apr 2004 07:06:20 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31C6HYG000079 for ; Thu, 1 Apr 2004 14:06:21 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 11:06:38 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2AA787LF>; Thu, 1 Apr 2004 11:06:38 +0200 Message-ID: <9547F8D6CC905145998556EF241A129C0669F195@ESEALNT876.al.sw.ericsson.se> From: "Jan Holm (AL/EAB)" To: "'xcon@ietf.org'" Date: Thu, 1 Apr 2004 11:06:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Apr 2004 09:06:38.0504 (UTC) FILETIME=[A3F7CA80:01C417C8] Subject: [XCON] Comments on the draft-ietf-xcon-floor-control-req-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.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, I am working with Push-To-Talk over Cellular (PoC) applications and looking into the floor control aspects. It looks like the requirements in this draft is close to the requirments for PoC. However when reading through the document I get the impression that 2 concepts are mixed (and that may be very logical and natural to do that): 1) There is a concept of a Concerence application. This concepts provides features like moderators, moderator control outside a conference mixing equipment, giving information about participants, etc. It can be expected that this part of the protocol may be byte consuming, and that it would best be expressed with some kind of xml schema. 2) There is a concept of floor control. Thisconcept provides floor requests, floor grant, floor revoke, etc. type of functionality. It can be expected that this protocol do not have to carry a lot of information. The name of the method (like "Floor request" would more or less be sufficent in many of the cases. From PoC point of view the last part is the part that, at least in the early phases, would be of interest. The question is is it possible to divide the requirement document into 2 parts. A Conference application part and a floor control part. This approach could make it possible to create 2 protocols Below follows some more detailed question about some of the requirements. ------------------------------------------------------------------------- REQ-2: It MUST be possible to group several media sessions in a conference together so that one floor applies to the group. Q: Does the above imply that the following combinations of floor and media can be defined: 1) All media type have a seperate floor. One can speak and one can send video. 2) Combine several media types for one floor and all media types granted at the same time. 3) Combine several media types for one floor but only one media granted at at the same time. -------------------------------------------------------------------- REQ-3: It MUST be possible to define who is allowed to create, change and remove a floor in a conference. We assume that the conference owner always has this privilege and may also authorize other entities, via the conference policy. Q: Can this requirement be removed since it has nothing to do with floor control. --------------------------- 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. It should be noted that efficient communication by means of minimal sized messages may contradict the desire to express reasons for requesting a floor (as per REQ-6) along with other information. Therefore, a floor control protocol SHOULD be designed in a way that it allow for expressive as well as minimal messaging, as (negotiable) configuration option and/or selectable on a per-message basis. Comment: Can a seperate less byte consuming protocol be developed for the floor control in order to support the above requirment. --------------------------------- REQ-20: There MAY be operations to manipulate the request set available for floor chair(s). Q: What does this requirement mean? /Regards Jan Holm _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Apr 1 08:09:30 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 IAA10420 for ; Thu, 1 Apr 2004 08:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91wO-0001zo-7e for xcon-archive@odin.ietf.org; Thu, 01 Apr 2004 08:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31D94sp007643 for xcon-archive@odin.ietf.org; Thu, 1 Apr 2004 08:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91wN-0001yK-Te for xcon-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 08:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10318 for ; Thu, 1 Apr 2004 08:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91wM-0007Zd-00 for xcon-web-archive@ietf.org; Thu, 01 Apr 2004 08:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91vO-0007Rv-00 for xcon-web-archive@ietf.org; Thu, 01 Apr 2004 08:08:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91uQ-0007Mh-00 for xcon-web-archive@ietf.org; Thu, 01 Apr 2004 08:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91uO-0001YR-Qc; Thu, 01 Apr 2004 08:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91tT-0001XH-Vu for xcon@optimus.ietf.org; Thu, 01 Apr 2004 08:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10205 for ; Thu, 1 Apr 2004 08:05:59 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91tS-0007IT-00 for xcon@ietf.org; Thu, 01 Apr 2004 08:06:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91sY-0007DA-00 for xcon@ietf.org; Thu, 01 Apr 2004 08:05:06 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B91sL-00079v-00 for xcon@ietf.org; Thu, 01 Apr 2004 08:04:53 -0500 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 i31D4p324975; Thu, 1 Apr 2004 16:04:51 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 16:04:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i31D4hQt004776; Thu, 1 Apr 2004 16:04:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 004H6oQK; Thu, 01 Apr 2004 16:04:41 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 i31D4Zs15601; Thu, 1 Apr 2004 16:04:35 +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, 1 Apr 2004 15:53:47 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 15:53:47 +0300 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 15:53:47 +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] Comments on the draft-ietf-xcon-floor-control-req-00.txt Date: Thu, 1 Apr 2004 15:53:45 +0300 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E9BD54@trebe004.europe.nokia.com> Thread-Topic: [XCON] Comments on the draft-ietf-xcon-floor-control-req-00.txt Thread-Index: AcQX4ohVWgGKFqKPTea3cLXNiH376wAAOJEw To: , X-OriginalArrivalTime: 01 Apr 2004 12:53:47.0515 (UTC) FILETIME=[5F7DD4B0:01C417E8] 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 Jan, Thanks for the comments. See inline. > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Jan Holm (AL/EAB) > Sent: 01 April, 2004 12:07 > To: 'xcon@ietf.org' > Subject: [XCON] Comments on the=20 > draft-ietf-xcon-floor-control-req-00.txt >=20 >=20 > Hi all, >=20 > I am working with Push-To-Talk over Cellular (PoC)=20 > applications and looking into the floor control aspects. >=20 > It looks like the requirements in this draft is close to the=20 > requirments for PoC. However when reading through the=20 > document I get the impression that 2 concepts are mixed (and=20 > that may be very logical and natural to do that): >=20 > 1) There is a concept of a Concerence application. This=20 > concepts provides features like moderators, moderator control=20 > outside a conference mixing equipment, giving information=20 > about participants, etc. It can be expected that this part of=20 > the protocol may be byte consuming, and that it would best be=20 > expressed with some kind of xml schema. >=20 > 2) There is a concept of floor control. Thisconcept provides=20 > floor requests, floor grant, floor revoke, etc. type of=20 > functionality. It can be expected that this protocol do not=20 > have to carry a lot of information. The name of the method=20 > (like "Floor request" would more or less be sufficent in many=20 > of the cases. This may be true in applications like PoC but in conferencing context floor control requests are expected to carry more information (e.g. the = topic of the question so moderator may decide to grant you the floor sooner in = the case=20 of long queue). >=20 > From PoC point of view the last part is the part that, at=20 > least in the early phases, would be of interest. >=20 >=20 > The question is is it possible to divide the requirement=20 > document into 2 parts. A Conference application part and a=20 > floor control part. This is already separated. Conference application (policy protocol) = takes care of mixer control, floor creation, appointing moderator etc.=20 Some of the (conf appl) requirements are also mentioned in this draft=20 but they will be moved to annex or separate section=20 (since they are covered in CPCP-reqs). >=20 > This approach could make it possible to create 2 protocols=20 Luckily, we are already creating two protocols: CPCP and FCP.=20 > Below follows some more detailed question about some of the=20 > requirements. > -------------------------------------------------------------- > ----------- > REQ-2: It MUST be possible to group several media sessions in a > conference together so that one floor applies to the group. >=20 > Q: Does the above imply that the following combinations of=20 > floor and media can be defined: >=20 > 1) All media type have a seperate floor. One can speak and one = can send video. Yes (2 separate floors). > 2) Combine several media types for one floor and all media types = granted at the same time. Yes (common floor). > 3) Combine several media types for one floor but only one media = granted at at the same time. No (if you are granted the common floor, they are reserved for you and = it is up to you to use or not to use them) >=20 > -------------------------------------------------------------------- > REQ-3: It MUST be possible to define who is allowed to=20 > create, change and remove a floor in a conference. We assume that the = conference > owner always has this privilege and may also authorize other > entities, via the conference policy. >=20 > Q: Can this requirement be removed since it has nothing to do=20 > with floor control. Yes, it will be moved to annex or separate section. >=20 > --------------------------- > REQ-17: Bandwidth and terminal limitations SHOULD be taken into > account in order to ensure that floor control can be=20 > efficiently used in mobile environments. >=20 > It should be noted that efficient communication by means of minimal > sized messages may contradict the desire to express reasons for > requesting a floor (as per REQ-6) along with other information. > Therefore, a floor control protocol SHOULD be designed in=20 > a way that it allow for expressive as well as minimal messaging, as=20 > (negotiable)configuration option and/or selectable on a per-message = basis. >=20 > Comment: Can a seperate less byte consuming protocol be=20 > developed for the floor control in order to support the above=20 > requirment. It may be difficult (since there may be many parameters and a lot of additional info in floor requests and responses). =20 > --------------------------------- > REQ-20: There MAY be operations to manipulate the request set > available for floor chair(s). >=20 > Q: What does this requirement mean? This is floor request queue manipulation in the server ("set" if used = instead of queue). -- Petri _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Apr 2 16:46: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 QAA03576 for ; Fri, 2 Apr 2004 16:46:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WUW-0003VU-CS for xcon-archive@odin.ietf.org; Fri, 02 Apr 2004 16:46:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LkINb013464 for xcon-archive@odin.ietf.org; Fri, 2 Apr 2004 16:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UzT-0001XR-2o for xcon-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 15:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26160 for ; Fri, 2 Apr 2004 15:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UzQ-0007Ki-00 for xcon-web-archive@ietf.org; Fri, 02 Apr 2004 15:10:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UyV-0007E6-00 for xcon-web-archive@ietf.org; Fri, 02 Apr 2004 15:09:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uy4-00076w-00 for xcon-web-archive@ietf.org; Fri, 02 Apr 2004 15:08:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S0Z-0005mW-5g; Fri, 02 Apr 2004 11:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Psx-0002gg-2G for xcon@optimus.ietf.org; Fri, 02 Apr 2004 09:43:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10793 for ; Fri, 2 Apr 2004 09:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Psv-0000Ry-00 for xcon@ietf.org; Fri, 02 Apr 2004 09:43:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Pru-0000Kr-00 for xcon@ietf.org; Fri, 02 Apr 2004 09:42:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B9PrO-0000DA-00 for xcon@ietf.org; Fri, 02 Apr 2004 09:41:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2004 06:41:26 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32EevKj022263; Fri, 2 Apr 2004 06:40:58 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn4-257.cisco.com [10.21.81.1]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANT21978; Fri, 2 Apr 2004 06:40:56 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 02 Apr 2004 06:33:48 -0800 Subject: Re: [XCON] Reminder: FC Reqs last call From: Cullen Jennings To: Adam Roach , XCON-IETF Message-ID: In-Reply-To: <9ACE0CEE075B494096C86C23878BF85906A3DB@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This document has a section titled "Open Issues" - that's enough proof for me that it is not ready to go to IESG. Particularly given the open issues is we have not figured out the security requirements. There are requirements - there is also an model of the solution. Is this also the framework document for floor control or just the requirements? Cullen On 3/22/04 10:04 AM, "Adam Roach" wrote: > As a reminder, we are currently conducting a last call > for the Floor Control Requirements document. This last > call period has two weeks remaining. > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Apr 2 16:47: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 QAA03714 for ; Fri, 2 Apr 2004 16:47:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WVQ-00040n-SY for xcon-archive@odin.ietf.org; Fri, 02 Apr 2004 16:47:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LlG3f015419 for xcon-archive@odin.ietf.org; Fri, 2 Apr 2004 16:47:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9V6A-00041R-Jd for xcon-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 15:17:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26782 for ; Fri, 2 Apr 2004 15:17:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9V69-0000On-00 for xcon-web-archive@ietf.org; Fri, 02 Apr 2004 15:17:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9V5B-0000FL-00 for xcon-web-archive@ietf.org; Fri, 02 Apr 2004 15:16:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9V4J-000079-00 for xcon-web-archive@ietf.org; Fri, 02 Apr 2004 15:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S0b-0005ns-P0; Fri, 02 Apr 2004 11:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Q6Q-0004Nq-Vy for xcon@optimus.ietf.org; Fri, 02 Apr 2004 09:57:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11225 for ; Fri, 2 Apr 2004 09:57:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q6P-0002Cn-00 for xcon@ietf.org; Fri, 02 Apr 2004 09:57:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Q5P-00024v-00 for xcon@ietf.org; Fri, 02 Apr 2004 09:56:00 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Q4i-0001rL-00 for xcon@ietf.org; Fri, 02 Apr 2004 09:55:16 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32Eshx19883 for ; Fri, 2 Apr 2004 08:54:43 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK5SXG>; Fri, 2 Apr 2004 15:54:42 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00BA85406@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: xcon@ietf.org Date: Fri, 2 Apr 2004 15:54:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Comments on draft-ietf-xcon-floor-control-req-00 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 I have the following comments on the above document. 1) I understand that it has been discussed to group the requirements. I would suggest that the appropriate grouping would be in the following categories. a) requirements relating to floor control protocol between floor participant and floor control server b) requirements relating to floor control protocol between floor chair and floor control server c) requirements relating to management of the floor control server by the conference server. I would suggest allocating the existing requirements as follows: a) REQ-5, REQ-6, REQ-8, REQ-10, REQ-12, REQ-13, REQ-14, REQ-17, REQ-18, REQ-19, REQ-a b) REQ-7, REQ-9, REQ-11, REQ-17, REQ-18, REQ-19, REQ-20, REQ-b c) REQ-1, REQ-2, REQ-3, REQ-4, REQ-15, REQ-16 2) In REQ-6, As phrased this requirement is a floor participant requirement. The second sentence actually identifies a further missing requirement that this additional information, if available, MUST be give to the floor chair. 3) In REQ-11, does the revoke also apply to a member of the floor control set, and thus remove that participant from the set? This is not a request for it to be a requirement to do so, merely to make clear what happens in this case. 4) In REQ-18, it may not be necessary to allow all participants to request information about floor control requests. This may be information that is better reserved to the floor chair. 5) In REQ-19, it may not be necessary to notify all participants about floor control requests. This may be information that is better reserved to the floor chair. 6) Notifications to participants, and the floor chair, are controlled by CPCP. We need a new requirement to indicate that this is so, and that such control can be excercised on a per participant basis. 7) There should be a new requirement that the floor chair can clear the current floor control set. Currently the only way the floor chair can manage the floor according to the requirements is to grant the floor and then revoke it, or to use CPCP to delete the floor entirely. If the floor chair, for example, wants to move on to the next agenda item, then then the requests of those waiting are no longer appropriate, and a new floor control set will need to be built up. 8) Conferences can be cascaded, such that a participant of the conference can be a conference in its own right. This has equivalent impact on floors and the associated floor control servers. There should be some guidelines on what is acceptable from a fllor control perspective at day 1, and what might be left to further study. 9) Do we require a security considerations section? regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Apr 5 06:31:35 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 GAA21143 for ; Mon, 5 Apr 2004 06:31: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 1BARNk-0003nw-Jl for xcon-archive@odin.ietf.org; Mon, 05 Apr 2004 06:31:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35AV8vv014625 for xcon-archive@odin.ietf.org; Mon, 5 Apr 2004 06:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARNk-0003no-7o for xcon-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 06:31: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 GAA21044 for ; Mon, 5 Apr 2004 06:31:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BARNg-0004zX-00 for xcon-web-archive@ietf.org; Mon, 05 Apr 2004 06:31:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BARMM-0004hV-00 for xcon-web-archive@ietf.org; Mon, 05 Apr 2004 06:29:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BARLZ-0004XJ-00 for xcon-web-archive@ietf.org; Mon, 05 Apr 2004 06:28:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARLb-0002g1-UQ; Mon, 05 Apr 2004 06:28:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPSo-0002lz-TO for xcon@optimus.ietf.org; Mon, 05 Apr 2004 04:28: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 EAA17102 for ; Mon, 5 Apr 2004 04:28:11 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPSm-00067k-00 for xcon@ietf.org; Mon, 05 Apr 2004 04:28:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPRr-00062R-00 for xcon@ietf.org; Mon, 05 Apr 2004 04:27:17 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BAPR7-0005x9-00 for xcon@ietf.org; Mon, 05 Apr 2004 04:26:30 -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 i358M8h04237; Mon, 5 Apr 2004 11:22:09 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 11:20:25 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i358KP2F017583; Mon, 5 Apr 2004 11:20:25 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00a1seSe; Mon, 05 Apr 2004 11:20:20 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 i358KKF11583; Mon, 5 Apr 2004 11:20:20 +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); Mon, 5 Apr 2004 11:18:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 11:18:41 +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] Open Issue: Hideable Participants Date: Mon, 5 Apr 2004 11:18:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797884@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Open Issue: Hideable Participants Thread-Index: AcQOATm4wDSedPsiQx28F9/hoFioFQM5KNOQ To: , Cc: , , , , , X-OriginalArrivalTime: 05 Apr 2004 08:18:41.0752 (UTC) FILETIME=[9AF14580:01C41AE6] 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 The issue has completely changed from "should a conference policy = indicate that a participant is hidden or not?" to "should a conference = policy indicate roles of participants?" The latter question requires the conference creator to know, beforehand, = the roles of the potential participants. I don't think that is feasible. If the roles are to be expressed as attributes in a URI or header, may I = suggest that this be a signalling protocol problem. I.e. When a = participant joins a conference by sending an INVITE (in SIP terms), then = it includes a header defining it role (or it can put a caps attribute in = the contact header). Similarly for the Dial outs, the participant = indicates it role in the 200 Ok. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Michael Hammer > Sent: 19.March.2004 23:21 > To: Paul Kyzivat > Cc: Rohan Mahy; xcon@ietf.org; Eric Burger; Rosen, Brian; 'Kozdon, > Peter'; 'Adam Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants >=20 >=20 > Likewise to the whole thread. (Apologies for the late comment.) >=20 > A user may not care whether an indicator is a primitive=20 > (attribute?) or a=20 > constructor (role?), but when I read the list of values=20 > suggested in this=20 > list thus far it is not clear to me which ones other than perhaps=20 > message-taker (a little vague as to what that means --=20 > verbatim or summary)=20 > or recorder will result in someone playing my words back to=20 > me and making=20 > me eat them. For legal purposes, any participant that records the=20 > conversation (probably audio or video) will need to have an=20 > unambiguous=20 > indication to each participant. Facilitator and automaton do=20 > not tell me=20 > much of anything. >=20 > Also, I would suggest (to keep clear of lawful intercept=20 > stuff) to describe=20 > this as "Displayable Participants". As Paul notes, this is=20 > really a UI=20 > issue, based on useful indications in the protocol. >=20 > Mike >=20 >=20 > At 05:27 PM 3/13/2004 -0500, Paul Kyzivat wrote: > >Replying to this whole thread, not just to Rohan... > > > >It seems to me that this discussion is replicating that=20 > which took place=20 > >around presence, in how to define "services". I have the=20 > impression that=20 > >what Brian is calling "role" here is similar to what others=20 > have called=20 > >"service" there. > > > >In the presence case we could find no useful unique way to define a=20 > >service, and decided it was largely in the eye of the=20 > beholder. So we=20 > >decided that we should just describe the features of a=20 > presentity, and let=20 > >the watchers interpret certain collections of features as a service. > > > >The same should work here, although the application is a bit=20 > simpler. It=20 > >is simply a matter of a client deciding what combination of features=20 > >constitue a participant that is/isn't interesting to that client. > > > >Whether "hideable" is a distinct feature is a separate=20 > question. I am=20 > >inclined to think it is not, because whether something is=20 > hideable is a=20 > >subjective decision, and not everyone will want to make the=20 > same decision. > > > > Paul > > > >Rohan Mahy wrote: > >>Paul, > >>On Mar 11, 2004, at 1:14 PM, Paul Kyzivat wrote: > >> > >>>Lets not get hung up on whether we call it a role or an=20 > attribute. Many=20 > >>>of the callee-caps things can be considered to be roles. > >>> > >>>Regarding Rohan saying there is another new attribute - I=20 > don't know=20 > >>>what that is. Are you talking about a "hideable"=20 > attribute? I don't=20 > >>>think that makes much sense. It puts the responsibility on=20 > the focus to=20 > >>>decide what should be hideable. > >> > >>yes. It makes the focus responsible for setting and believing this=20 > >>attribute. I think this is an excellent thing. IMO, the=20 > focus is the=20 > >>only entity that can do a reasonable job of this. > >> > >>>I think it is better for clients to each decide what they=20 > do/don't want=20 > >>>to see. I may want to hide automata and attendants except=20 > that I want to=20 > >>>see recorders. You may just decide to hide automata. > >> > >>feel free to do that, but you may not like the results. =20 > what if the=20 > >>predominantly interesting thing in the conference is an=20 > automaton with=20 > >>VCR-style controls that the humans in the group are=20 > annotating? What if=20 > >>the automata is providing other useful information as a participant=20 > >>(rendering a summary of last months sales figures for=20 > example). I think=20 > >>the "ignore automatons" approach. It also doesn't allow=20 > you to ignore=20 > >>the "tea lady" participant or the "human scribe" participant. > >> > >>>Regarding how to denote a recorder, I think the existing=20 > message-taker=20 > >>>feature tag is probably close enough for the purpose. > >> > >>this may be reasonable, but there are slightly different routing=20 > >>semantics if I want my call routed to someone/something who=20 > can take a=20 > >>message for me, and something that just records what I said. > >> > >>>I think what we are talking about can be achieved by exposing the=20 > >>>contact parameters from each participant in CPCP. > >> > >>sometimes. > >>thanks, > >>-r > >> > >>> Paul > >>> > >>>Rosen, Brian wrote: > >>> > >>>>What attributes does an IVR box have besides automaton? > >>>>How about a caption service? > >>>>If we create a caps for each service, all orthogonal, is that > >>>>you think makes sense? > >>>>These are all roles, they are not attributes. > >>>>Brian > >>>> > >>>>>-----Original Message----- > >>>>>From: Rohan Mahy [mailto:rohan@cisco.com] > >>>>>Sent: Thursday, March 11, 2004 3:47 PM > >>>>>To: Rosen, Brian > >>>>>Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon,=20 > Peter'; 'Adam > >>>>>Roach' > >>>>>Subject: Re: [XCON] Open Issue: Hideable Participants > >>>>> > >>>>> > >>>>>Hi, > >>>>> > >>>>>I'd like to apologize to the group that some=20 > of these=20 > >>>>>ideas are SIP-specific or very SIP influenced > >>>>> > >>>>>Here are the binary or ternary attributes that already=20 > exist from=20 > >>>>>draft-ietf-sip-callee-caps: > >>>>> > >>>>>automaton/human > >>>>>personal/business > >>>>>mobile/fixed > >>>>>duplex/send-only/receive-only > >>>>> > >>>>>these are 100% orthogonal with respect to each other > >>>>> > >>>>>Various folks have proposed that we need the following=20 > additional=20 > >>>>>attributes in various parts of conferencing and/or signaling: > >>>>> > >>>>>interactive/noninteractive > >>>>>anonymous/identified > >>>>> > >>>>>(again, these are 100% orthogonal with respect to each=20 > other and the=20 > >>>>>other attributes) > >>>>> > >>>>>finally I am proposing this new attribute we have been=20 > describing=20 > >>>>>here. I believe this is still highly orthogonal to the=20 > other attributes. > >>>>> > >>>>>I believe this new attribute is more appropriate than an=20 > enumerations=20 > >>>>>for two main reasons: > >>>>> > >>>>>1) you can code behavior based on the presence of the attribute=20 > >>>>>directly rather than checking for a bunch different=20 > roles and then=20 > >>>>>making sure there are not conditions attached to those roles. > >>>>>2) it allows a new thing/role to exist which we haven't=20 > thought of yet=20 > >>>>>that can still unambiguously provide its attributes. =20 > existing code=20 > >>>>>will work quite well with this new thing if it describes=20 > itself using=20 > >>>>>(in part) a number of existing attributes. > >>>>> > >>>>>thanks, > >>>>>-rohan > >>>>> > >>>>> > >>>>>On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > >>>>> > >>>>> > >>>>>>Rohan > >>>>>> > >>>>>>I'm not sure I agree. I clearly do want to provide > >>>>> > >>>>> > >>>>>information across > >>>>> > >>>>>>the wire unambiguously, but I don't think a lot of=20 > binary attributes > >>>>>>is a good way to do that. I think we are talking about a > >>>>> > >>>>> > >>>>>role, rather > >>>>> > >>>>>>than an attribute. A single automaton, like a single > >>>>> > >>>>> > >>>>>human, is capable > >>>>> > >>>>>>of multiple roles, so you need a list in both cases. > >>>>>> > >>>>>>Brian > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: Rohan Mahy [mailto:rohan@cisco.com] > >>>>>>>Sent: Thursday, March 11, 2004 2:24 PM > >>>>>>>To: Rosen, Brian > >>>>>>>Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon,=20 > Peter'; 'Adam > >>>>>>>Roach' > >>>>>>>Subject: Re: [XCON] Open Issue: Hideable Participants > >>>>>>> > >>>>>>> > >>>>>>>Brian, > >>>>>>> > >>>>>>>There are many different orthogonal attributes we should be > >>>>>>>able to get > >>>>>>>access to. This "non-interesting" participant or "facilitator" > >>>>>>>attribute is orthogonal to your status as an automaton=20 > or human. I > >>>>>>>don't think an enumeration here is a good substitute for this > >>>>>>>attribute. It may be that indicating a recorder is a good > >>>>>>>value to add > >>>>>>>to the "actor" media feature tag, which currently has=20 > a msg-taker > >>>>>>>value, or that we can reuse the msg-taker value for the > >>>>>>>recorder. The > >>>>>>>goal is maximum orthogonality. We probably can't=20 > achieve complete > >>>>>>>orthogonality but I think we can get very close. > >>>>>>> > >>>>>>>thanks, > >>>>>>>-rohan > >>>>>>> > >>>>>>> > >>>>>>>On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > >>>>>>> > >>>>>>> > >>>>>>>>Seems to me that you are on the right track, but we need to > >>>>>>> > >>>>>>> > >>>>>>>go farther. > >>>>>>> > >>>>>>>>We have to classify these participants so that the UI, if > >>>>>>> > >>>>>>> > >>>>>>>it wanted to, > >>>>>>> > >>>>>>>>could render an appropriate indication. The example of > >>>>>>> > >>>>>the recorder > >>>>> > >>>>>>>>is pretty compelling. Just knowing that there is an=20 > automaton out > >>>>>>>>there > >>>>>>>>is one thing. Knowing its a recorder is another. =20 > So, really you > >>>>>>>>don't want a flag, you want an enunumeration. It may=20 > actually be > >>>>>>>>a list, because a single automaton could have=20 > multiple functions. > >>>>>>>> > >>>>>>>>Brian > >>>>>>>> > >>>>>>>> > >>>>>>>>>-----Original Message----- > >>>>>>>>>From: Adam Roach [mailto:adam@dynamicsoft.com] > >>>>>>>>>Sent: Thursday, March 11, 2004 12:27 AM > >>>>>>>>>To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > >>>>>>>>>Subject: RE: [XCON] Open Issue: Hideable Participants > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>[not as chair] > >>>>>>>>> > >>>>>>>>>I don't think anyone is currently arguing whether indication > >>>>>>>>>of such automata should be available to the users. Most > >>>>>>>>>of what I've heard people say on this list -- after Korea, > >>>>>>>>>at least -- seems to agree that such elements *should* > >>>>>>>>>be indicated in the protocol. Note that this is not the > >>>>>>>>>same thing as saying that they must be forcibly rendered > >>>>>>>>>to users regardless of the users want, which is what you > >>>>>>>>>seem to be arguing for. > >>>>>>>>> > >>>>>>>>>What I've heard -- and I agree with this viewpoint -- is > >>>>>>>>>that there should be some flag that indicates "this element > >>>>>>>>>is a facilitator, not a participant," so that users who don't > >>>>>>>>>*care* about seeing such elements (existence proof: me) > >>>>>>>>>could configure their clients not to display them. > >>>>>>>>> > >>>>>>>>>To expand on the flag's meaning, it would make the most > >>>>>>>>>sense to have it mean more precisely "this element is not > >>>>>>>>>truly a participant, but is providing some service related > >>>>>>>>>to the conference." In other words, I would want it to > >>>>>>>>>cover e.g. human transcribers, human translators, etc., > >>>>>>>>>in addition to automata. > >>>>>>>>> > >>>>>>>>>As Eric points out, I think people are getting hung up on > >>>>>>>>>the name without thinking the issue through completely. > >>>>>>>>>I've updated the subject line accordingly. > >>>>>>>>> > >>>>>>>>>/a > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>-----Original Message----- > >>>>>>>>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>>>>>>Sent: Wednesday, March 10, 2004 20:50 > >>>>>>>>>>To: Eric Burger; xcon@ietf.org > >>>>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>I agree that automatons are processing resources=20 > and could be > >>>>>>>>>>considered as > >>>>>>>>>>logical parts of the conference fabric, for example an IVR > >>>>>>>>>>could monitor the > >>>>>>>>>>conference and provide a trigger in response to a phrase > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>that could be > >>>>>>>>> > >>>>>>>>>>consumed elsewhere. Similarly a device that announces > >>>>>>>>>>participants, etc.. > >>>>>>>>>>However, IMHO a conference recorder does not fall into this > >>>>>>>>>>category and > >>>>>>>>>>should probably be a visible resource maybe with an > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>indicator to show > >>>>>>>>> > >>>>>>>>>>whether it is or is not active. Similarly - a player > >>>>>>>>> > >>>>>>>resources which > >>>>>>> > >>>>>>>>>>delivers content or information to the conference=20 > should also > >>>>>>>>>>be visible - > >>>>>>>>>>it seems desirable to know where such content is=20 > coming from. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>-----Original Message----- > >>>>>>>>>>From: Eric Burger [mailto:eburger@snowshore.com] > >>>>>>>>>>Sent: Tuesday, March 09, 2004 1:28 PM > >>>>>>>>>>To: Kozdon, Peter; xcon@ietf.org > >>>>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>>>> > >>>>>>>>>>I think we got caught up on the name. > >>>>>>>>>> > >>>>>>>>>>There are two needs. > >>>>>>>>>> > >>>>>>>>>>The first, which I think we may have consensus on, is the > >>>>>>>>>>need for anonymous > >>>>>>>>>>participants. That is, participants that are present in the > >>>>>>>>>>conference, but > >>>>>>>>>>do not have their identities revealed. > >>>>>>>>>> > >>>>>>>>>>The second, which is more blurry, is the need for > >>>>>>>>>>participants that are > >>>>>>>>>>truly hidden. Some want to use hidden participants for > >>>>>>>>>>automatons, e.g., > >>>>>>>>>>IVR systems or conference recorders. (IMHO, bad idea, but > >>>>>>>>>>that is really > >>>>>>>>>>just MHO, not strictly black-and-white.) > >>>>>>>>>> > >>>>>>>>>>We do have consensus that Lawful Intercept is entirely > >>>>>>>>> > >>>>>>>orthogonal to > >>>>>>> > >>>>>>>>>>conference participants. However, the logic of the above > >>>>>>>>>>follows. Just as > >>>>>>>>>>IVR systems or conference recorders are not really > >>>>>>>>>>participants, neither is > >>>>>>>>>>LI hardware. If we say that the approach for IVR=20 > is to plumb > >>>>>>>>>>in as a hidden > >>>>>>>>>>participant, then LI would have the same approach. =20 > If we say > >>>>>>>>>>that IVR is > >>>>>>>>>>something different, e.g., just a part of the conference > >>>>>>>>>>mixer, then it is > >>>>>>>>>>truly "not there". Likewise, I would expect LI to be > >>>>>>>>> > >>>>>>>"not there" -- > >>>>>>> > >>>>>>>>>>something outside the XCON framework entirely. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>-----Original Message----- > >>>>>>>>>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>>>>>>>Sent: Monday, March 08, 2004 6:28 PM > >>>>>>>>>>>To: 'xcon@ietf.org' > >>>>>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>Hidden listeners operation is probably illegal in many US > >>>>>>>>>> > >>>>>>>>>states as > >>>>>>>>> > >>>>>>>>>>>well as in many countries - when you make a call there is a > >>>>>>>>>>>requirement in California the all parties are aware of the > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>presence of > >>>>>>>>>> > >>>>>>>>>>>a 3rd party or recording device, note- that party may be > >>>>>>>>>> > >>>>>>>>>anonymous, > >>>>>>>>> > >>>>>>>>>>>etc.. > >>>>>>>>>>>(Exception -- > >>>>>>>>>>>legal intercept.) > >>>>>>>>>>> > >>>>>>>>>>>We should follow the similar logic for XCON - provide an > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>indication of > >>>>>>>>>> > >>>>>>>>>>>a recording device and/or anonymous participant's) > >>>>>>>>>>> > >>>>>>>>>>>Peter Kozdon > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>-----Original Message----- > >>>>>>>>>>>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > >>>>>>>>>> > >>>>>>>>>Behalf Of > >>>>>>>>> > >>>>>>>>>>>Adam Roach > >>>>>>>>>>>Sent: Monday, March 08, 2004 12:04 PM > >>>>>>>>>>>To: 'xcon@ietf.org' > >>>>>>>>>>>Subject: [XCON] Open Issue: Hidden Participants > >>>>>>>>>>> > >>>>>>>>>>>[as chair] > >>>>>>>>>>> > >>>>>>>>>>>At the XCON meeting, there was a rather lively=20 > discussion that > >>>>>>>>>>>continued the "Hidden Participants" discussion that had > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>started on the > >>>>>>>>>> > >>>>>>>>>>>list. It was agreed that the topic was worth discussion, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>but that we > >>>>>>>>>> > >>>>>>>>>>>did not have enough time to pursue it in the meeting. > >>>>>>>>>>> > >>>>>>>>>>>I'm calling on everyone, especially those involved in > >>>>>>>>>> > >>>>>the meeting > >>>>> > >>>>>>>>>>>discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > >>>>>>>>>> > >>>>>>>>>continue this > >>>>>>>>> > >>>>>>>>>>>discussion so we can close this issue in the near future. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>Alan and I > >>>>>>>>>> > >>>>>>>>>>>would like to be able to last-call this document shortly, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>and this is > >>>>>>>>>> > >>>>>>>>>>>the key issue that needs to be resolved before a new > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>revision of the > >>>>>>>>>> > >>>>>>>>>>>draft can be produced. > >>>>>>>>>>> > >>>>>>>>>>>/a > >>>>>>>>>>> > >>>>>>>>>>>_______________________________________________ > >>>>>>>>>>>XCON mailing list > >>>>>>>>>>>XCON@ietf.org > >>>>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>>>>> > >>>>>>>>>>>_______________________________________________ > >>>>>>>>>>>XCON mailing list > >>>>>>>>>>>XCON@ietf.org > >>>>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>_______________________________________________ > >>>>>>>>>>XCON mailing list > >>>>>>>>>>XCON@ietf.org > >>>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>>> > >>>>>>>>>_______________________________________________ > >>>>>>>>>XCON mailing list > >>>>>>>>>XCON@ietf.org > >>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>XCON mailing list > >>>>>>>>XCON@ietf.org > >>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>> > >>>>_______________________________________________ > >>>>XCON mailing list > >>>>XCON@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/xcon > >>> > > > > > >_______________________________________________ > >XCON mailing list > >XCON@ietf.org > >https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Apr 5 12:48: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 MAA14658 for ; Mon, 5 Apr 2004 12:48: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 1BAXGm-0005Ff-SN for xcon-archive@odin.ietf.org; Mon, 05 Apr 2004 12:48:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35GmKFk020188 for xcon-archive@odin.ietf.org; Mon, 5 Apr 2004 12:48:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXGm-0005FX-Ob for xcon-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 12:48: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 MAA14575 for ; Mon, 5 Apr 2004 12:48:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAXGl-000397-00 for xcon-web-archive@ietf.org; Mon, 05 Apr 2004 12:48:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXE7-0002hY-00 for xcon-web-archive@ietf.org; Mon, 05 Apr 2004 12:45:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAXCb-0002SJ-00 for xcon-web-archive@ietf.org; Mon, 05 Apr 2004 12:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXCY-0001Qi-EN; Mon, 05 Apr 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 1BAWb8-0002io-Gj for xcon@optimus.ietf.org; Mon, 05 Apr 2004 12:05: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 MAA10064 for ; Mon, 5 Apr 2004 12:05:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWb2-0003xX-00 for xcon@ietf.org; Mon, 05 Apr 2004 12:05:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWOV-00021K-00 for xcon@ietf.org; Mon, 05 Apr 2004 11:52:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BAWDK-0007lq-00 for xcon@ietf.org; Mon, 05 Apr 2004 11:40:42 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2004 08:38:37 -0700 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i35Fe9CC018676; Mon, 5 Apr 2004 11:40:09 -0400 (EDT) Received: from mhammer-w2k03.cisco.com ([64.100.229.254]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AYF38898; Mon, 5 Apr 2004 08:40:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20040405113606.02b69708@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 11:40:08 -0400 To: "Drage, Keith (Keith)" From: Michael Hammer Subject: Re: [XCON] Comments on draft-ietf-xcon-floor-control-req-00 Cc: xcon@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB00BA85406@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 03:54 PM 4/2/2004 +0100, Drage, Keith (Keith) wrote: >4) In REQ-18, it may not be necessary to allow all participants to >request information about floor control requests. This may be information >that is better reserved to the floor chair. > >5) In REQ-19, it may not be necessary to notify all participants >about floor control requests. This may be information that is better >reserved to the floor chair. Could someone clarify that the floor control requests are status elements visible in a specific view to the floor chair at least until they are granted or denied (cleared)? What I am concerned about is the ability for a floor chair to drop out of a conference and for another participant to pick up as "vice-chair". Presumable, requests that have been made prior to the transition, but not acted upon will be transferrable. Mike _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Apr 6 06:10:51 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 GAA28555 for ; Tue, 6 Apr 2004 06:10: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 1BAnXF-0007qE-NK for xcon-archive@odin.ietf.org; Tue, 06 Apr 2004 06:10:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36AAPOs030142 for xcon-archive@odin.ietf.org; Tue, 6 Apr 2004 06:10:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnXF-0007q5-IZ for xcon-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 06:10: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 GAA28399 for ; Tue, 6 Apr 2004 06:10:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnXB-0001cJ-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 06:10:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAn5y-0006M1-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 05:42:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAmoJ-0004ZG-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 05:23:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoL-0005JK-1r; Tue, 06 Apr 2004 05:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmna-000513-EY for xcon@optimus.ietf.org; Tue, 06 Apr 2004 05:23: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 FAA25857 for ; Tue, 6 Apr 2004 05:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmnX-0004Oa-00 for xcon@ietf.org; Tue, 06 Apr 2004 05:23:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmef-0002an-00 for xcon@ietf.org; Tue, 06 Apr 2004 05:14:02 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BAmGO-0007Lr-00 for xcon@ietf.org; Tue, 06 Apr 2004 04:48:56 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i368mO116809 for ; Tue, 6 Apr 2004 03:48:24 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK7HM1>; Tue, 6 Apr 2004 09:48:23 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439F045@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Michael Hammer'" Cc: xcon@ietf.org Subject: RE: [XCON] Comments on draft-ietf-xcon-floor-control-req-00 Date: Tue, 6 Apr 2004 09:48:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 My understanding of the way this works is that all floor requests are contained in the "floor control set". Any change of floor control chair is handled by CPCP, but this does not need to have an impact on the contents of the floor control set. (As far as floor control is concerned, users are either chairs or participants, there is no concept of vice chair). Of course CPCP could also remove the floor entirely and all sorts of other floor modifications in between. Any chair, including a new chair recently allocated by CPCP (or according to the current requirements any participant) can review the current floor control set, and therefore allocate a vacant floor to an entry in the floor control set. Note there is also nothing that prevents more than one chair to a floor, so this change of floor chair could also be handled by mutual agreement, outside the CPCP and the floor control protocol, directly between existing floor chairs. regards Keith > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: 05 April 2004 16:40 > To: Drage, Keith (Keith) > Cc: xcon@ietf.org > Subject: Re: [XCON] Comments on draft-ietf-xcon-floor-control-req-00 > > > At 03:54 PM 4/2/2004 +0100, Drage, Keith (Keith) wrote: > >4) In REQ-18, it may not be necessary to allow all > participants to > >request information about floor control requests. This may > be information > >that is better reserved to the floor chair. > > > >5) In REQ-19, it may not be necessary to notify all > participants > >about floor control requests. This may be information that is better > >reserved to the floor chair. > > Could someone clarify that the floor control requests are > status elements > visible in a specific view to the floor chair at least until they are > granted or denied (cleared)? > > What I am concerned about is the ability for a floor chair to > drop out of a > conference and for another participant to pick up as > "vice-chair". Presumable, requests that have been made prior to the > transition, but not acted upon will be transferrable. > > Mike > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Apr 6 16:14:49 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 QAA24945 for ; Tue, 6 Apr 2004 16:14: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 1BAwxi-0002Mo-JR for xcon-archive@odin.ietf.org; Tue, 06 Apr 2004 16:14:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36KEMcB009096 for xcon-archive@odin.ietf.org; Tue, 6 Apr 2004 16:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwxi-0002Md-GR for xcon-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:14:22 -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 QAA24816 for ; Tue, 6 Apr 2004 16:14:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwxg-00046W-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 16:14:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwPQ-0005pj-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 15:38:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAvUV-00002E-02 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 14:40:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvSU-0001jh-0W; Tue, 06 Apr 2004 14:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuzH-0008JH-9O for xcon@optimus.ietf.org; Tue, 06 Apr 2004 14:07: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 OAA12743 for ; Tue, 6 Apr 2004 14:07:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuzE-0002Ly-00 for xcon@ietf.org; Tue, 06 Apr 2004 14:07:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAutC-0001Id-00 for xcon@ietf.org; Tue, 06 Apr 2004 14:01:35 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BAujr-0000BK-00 for xcon@ietf.org; Tue, 06 Apr 2004 13:51:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 10:00:12 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i36HpMGF010497; Tue, 6 Apr 2004 10:51:23 -0700 (PDT) Received: from [128.107.171.27] ([128.107.171.27]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANV40704; Tue, 6 Apr 2004 10:51:21 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 06 Apr 2004 10:51:23 -0700 From: Cullen Jennings To: Cullen Jennings , XCON-IETF Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Stop the Start Time 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 Requirements related to time and conferences. Need to be able to specify what time the dial begins. Need to be able to specify time that media mixing will not happen before and also time that mixing will not continue after. These times are optional. All times are in GMT and there is no need for time zones. Need to be able to specify if mixing happens before a participant with some specialized role joins and if it continues after all the participants with some specialized role leave. This is to support conference where mixing does not happen when the owner of the conference is not present. A resolution of 1 second is adequate for all these times. A a side note, I feel that start and stop time are a confusing term to use for any of the times above. It might be a good idea to specify a single "conference time" in absolute terms then specify the rest of the times as deltas from that. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Apr 6 16:14:50 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 QAA24961 for ; Tue, 6 Apr 2004 16:14:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwxi-0002MX-Do for xcon-archive@odin.ietf.org; Tue, 06 Apr 2004 16:14:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36KEM0v009082 for xcon-archive@odin.ietf.org; Tue, 6 Apr 2004 16:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwxi-0002MP-0E for xcon-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:14:22 -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 QAA24813 for ; Tue, 6 Apr 2004 16:14:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwxg-00046Q-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 16:14:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwPP-0005pY-00 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 15:38:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAvUV-00002E-01 for xcon-web-archive@ietf.org; Tue, 06 Apr 2004 14:40:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvSU-0001jp-8o; Tue, 06 Apr 2004 14:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuzK-0008Ja-CM for xcon@optimus.ietf.org; Tue, 06 Apr 2004 14:07: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 OAA12751 for ; Tue, 6 Apr 2004 14:07:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuzI-0002MH-00 for xcon@ietf.org; Tue, 06 Apr 2004 14:07:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAutF-0001Jq-00 for xcon@ietf.org; Tue, 06 Apr 2004 14:01:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BAujv-0000BK-00 for xcon@ietf.org; Tue, 06 Apr 2004 13:52:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 10:00:47 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i36HpvKj013414; Tue, 6 Apr 2004 10:51:57 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARU49930; Tue, 6 Apr 2004 10:51:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <569D2830-87F3-11D8-BF5F-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: Dean Willis , Hisham Khartabil , Allison Mankin , Robert Sparks , John Peterson , Ted Hardie , Gonzalo Camarillo , Rohan Mahy , Alan Johnston , Adam Roach From: Rohan Mahy Date: Tue, 6 Apr 2004 10:53:40 -0700 To: "'xcon@ietf.org'" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [XCON] Joint Interim Meeting Mon May 24 - Wed May 26 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, Please mark your calendars. I'd like to announce a joint interim of the SIP, SIPPING, SIMPLE, and XCON WGs. Nokia has generously agreed to host the event either at their offices near Boston or in a neighboring hotel during the week of May 24. Please reserve the following dates for the WGs that you are interested in: Monday May 24 SIP and SIPPING tentatively 9 am start Tuesday May 25 SIMPLE All day Wednesday May 26 XCON tentatively finish at 4pm so folks can catch flights. (the actual agenda is subject to change, including the dates of various WG meetings). There will be no fee, however please let Hisham and myself know if you are planning to attend by clicking on the Yes or Maybe links below: mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]yes mailto:rohan@cisco.com? Cc=hisham.khartabil@nokia.com&Subject=[interim]maybe Wireless will be provided. As usual, I will be making T-shirts. If you are interested in buying one, please send your shirt size to me. More details on the agenda and hotel accommodations will be forthcoming shortly. thanks, -rohan _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Apr 7 07:55: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 HAA14849 for ; Wed, 7 Apr 2004 07:55: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 1BBBdk-0006zf-8T for xcon-archive@odin.ietf.org; Wed, 07 Apr 2004 07:54:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BsiY2026880 for xcon-archive@odin.ietf.org; Wed, 7 Apr 2004 07:54:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBdj-0006xz-Lg for xcon-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 07:54: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 HAA14790 for ; Wed, 7 Apr 2004 07:54:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBdi-0002u9-00 for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 07:54:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAub-00048p-00 for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 07:08:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BB9e6-0003Sv-00 for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 05:46:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9e8-0006ru-Sk; Wed, 07 Apr 2004 05:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB9dl-0006rT-Sk for xcon@optimus.ietf.org; Wed, 07 Apr 2004 05:46:37 -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 FAA02391 for ; Wed, 7 Apr 2004 05:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB9di-0003Qp-00 for xcon@ietf.org; Wed, 07 Apr 2004 05:46:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB8ai-0002wt-00 for xcon@ietf.org; Wed, 07 Apr 2004 04:39:26 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BB7Qz-0002rK-00 for xcon@ietf.org; Wed, 07 Apr 2004 03:25:17 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Apr 2004 10:24:46 +0300 Message-ID: From: "Even, Roni" To: "'Cullen Jennings'" , XCON-IETF Subject: RE: [XCON] Stop the Start Time Date: Wed, 7 Apr 2004 10:24:42 +0300 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 Cullen, "Need to be able to specify if mixing happens before a participant with some specialized role joins and if it continues after all the participants with some specialized role leave. This is to support conference where mixing does not happen when the owner of the conference is not present." These are not time requirement, they apply to conference in general. A similar requirement is to be able to specify if the conference can be extended (manually or automatic) Roni ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, April 06, 2004 7:51 PM To: Cullen Jennings; XCON-IETF Subject: [XCON] Stop the Start Time Requirements related to time and conferences. Need to be able to specify what time the dial begins. Need to be able to specify time that media mixing will not happen before and also time that mixing will not continue after. These times are optional. All times are in GMT and there is no need for time zones. Need to be able to specify if mixing happens before a participant with some specialized role joins and if it continues after all the participants with some specialized role leave. This is to support conference where mixing does not happen when the owner of the conference is not present. A resolution of 1 second is adequate for all these times. A a side note, I feel that start and stop time are a confusing term to use for any of the times above. It might be a good idea to specify a single "conference time" in absolute terms then specify the rest of the times as deltas from that. _______________________________________________ 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 Apr 7 21:55:21 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 VAA06644 for ; Wed, 7 Apr 2004 21:55:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOkn-00021G-Ip for xcon-archive@odin.ietf.org; Wed, 07 Apr 2004 21:54:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i381sroM007760 for xcon-archive@odin.ietf.org; Wed, 7 Apr 2004 21:54:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOkm-00020G-Ru for xcon-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 21:54: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 VAA06466 for ; Wed, 7 Apr 2004 21:54:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOkk-0000bt-00 for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 21:54:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNWJ-0003RY-00 for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 20:35:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBLCM-00053s-00 for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 18:07:06 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBLCN-0003IM-4R for xcon-web-archive@ietf.org; Wed, 07 Apr 2004 18:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLCK-0000In-5H; Wed, 07 Apr 2004 18:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLCE-0000DP-9P for xcon@optimus.ietf.org; Wed, 07 Apr 2004 18:06:58 -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 SAA15208 for ; Wed, 7 Apr 2004 18:06:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBLCB-000529-00 for xcon@ietf.org; Wed, 07 Apr 2004 18:06:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBJzx-0000oc-00 for xcon@ietf.org; Wed, 07 Apr 2004 16:50:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BBHt4-0003ML-00 for xcon@ietf.org; Wed, 07 Apr 2004 14:34:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2004 10:43:28 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i37IYPn2007723; Wed, 7 Apr 2004 11:34:25 -0700 (PDT) Received: from [10.32.130.93] ([10.32.130.93]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANW47692; Wed, 7 Apr 2004 11:34:24 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 07 Apr 2004 11:26:41 -0700 Subject: Re: [XCON] Stop the Start Time From: Cullen Jennings To: Roni Even , XCON-IETF Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hmm, well I don't know if I get the difference between time requirements and general requirements but I don't know if it is important as long as we agree on what the requirements are. If the conference can be automatically extended, then the "must not mix after time" is infinite. If the the conference is manually extended, then it is just that the "must not mix after time" has been modified and the policy of who is allowed to change this conference parameter is the same policy problem of who is allowed to change anything else in CPCP. Cullen On 4/7/04 12:24 AM, "Even, Roni" wrote: > Cullen, > > "Need to be able to specify if mixing happens before a participant with some > specialized role joins and if > it continues after all the participants with some specialized role leave. > This is to support conference where mixing does not happen when the owner of > the conference is not present." > > These are not time requirement, they apply to conference in general. A > similar requirement is to be able to specify if the conference can be > extended (manually or automatic) > > Roni > > > ************************************* > Roni Even > VP Product Planning > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, April 06, 2004 7:51 PM > To: Cullen Jennings; XCON-IETF > Subject: [XCON] Stop the Start Time > > > > Requirements related to time and conferences. > > Need to be able to specify what time the dial begins. Need to be able to > specify time that media mixing will not happen before and also time that > mixing will not continue after. These times are optional. All times are in > GMT and there is no need for time zones. Need to be able to specify if > mixing happens before a participant with some specialized role joins and if > it continues after all the participants with some specialized role leave. > This is to support conference where mixing does not happen when the owner of > the conference is not present. A resolution of 1 second is adequate for all > these times. > > A a side note, I feel that start and stop time are a confusing term to use > for any of the times above. It might be a good idea to specify a single > "conference time" in absolute terms then specify the rest of the times as > deltas from that. > > > > > > > _______________________________________________ > 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 Apr 8 13:38:46 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 NAA07102 for ; Thu, 8 Apr 2004 13:38: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 1BBdTj-0004ua-LU for xcon-archive@odin.ietf.org; Thu, 08 Apr 2004 13:38:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38HcFul018880 for xcon-archive@odin.ietf.org; Thu, 8 Apr 2004 13:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdTi-0004uN-7q for xcon-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 13:38: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 NAA07067 for ; Thu, 8 Apr 2004 13:38:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdTf-0004TW-00 for xcon-web-archive@ietf.org; Thu, 08 Apr 2004 13:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBazM-0003az-00 for xcon-web-archive@ietf.org; Thu, 08 Apr 2004 10:58:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBYtx-0003VQ-00 for xcon-web-archive@ietf.org; Thu, 08 Apr 2004 08:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYtx-0007MT-UQ; Thu, 08 Apr 2004 08:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYt7-0007IK-1g for xcon@optimus.ietf.org; Thu, 08 Apr 2004 08:44: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 IAA12307 for ; Thu, 8 Apr 2004 08:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBYt5-0003MX-00 for xcon@ietf.org; Thu, 08 Apr 2004 08:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBWYa-0003bZ-00 for xcon@ietf.org; Thu, 08 Apr 2004 06:14:49 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BBUnC-0003Dd-00 for xcon@ietf.org; Thu, 08 Apr 2004 04:21:46 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Apr 2004 11:21:15 +0300 Message-ID: From: "Even, Roni" To: "'Cullen Jennings'" , XCON-IETF Subject: RE: [XCON] Stop the Start Time Date: Thu, 8 Apr 2004 11:21:14 +0300 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 Cullen, Extending is not the same as the must not mix after time. For the initial length of the conference, resources are guaranteed while extension is typically on best effort. So these should be different parameters Roni ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Wednesday, April 07, 2004 8:27 PM To: Roni Even; XCON-IETF Subject: Re: [XCON] Stop the Start Time Hmm, well I don't know if I get the difference between time requirements and general requirements but I don't know if it is important as long as we agree on what the requirements are. If the conference can be automatically extended, then the "must not mix after time" is infinite. If the the conference is manually extended, then it is just that the "must not mix after time" has been modified and the policy of who is allowed to change this conference parameter is the same policy problem of who is allowed to change anything else in CPCP. Cullen On 4/7/04 12:24 AM, "Even, Roni" wrote: > Cullen, > > "Need to be able to specify if mixing happens before a participant with some > specialized role joins and if > it continues after all the participants with some specialized role leave. > This is to support conference where mixing does not happen when the owner of > the conference is not present." > > These are not time requirement, they apply to conference in general. A > similar requirement is to be able to specify if the conference can be > extended (manually or automatic) > > Roni > > > ************************************* > Roni Even > VP Product Planning > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, April 06, 2004 7:51 PM > To: Cullen Jennings; XCON-IETF > Subject: [XCON] Stop the Start Time > > > > Requirements related to time and conferences. > > Need to be able to specify what time the dial begins. Need to be able to > specify time that media mixing will not happen before and also time that > mixing will not continue after. These times are optional. All times are in > GMT and there is no need for time zones. Need to be able to specify if > mixing happens before a participant with some specialized role joins and if > it continues after all the participants with some specialized role leave. > This is to support conference where mixing does not happen when the owner of > the conference is not present. A resolution of 1 second is adequate for all > these times. > > A a side note, I feel that start and stop time are a confusing term to use > for any of the times above. It might be a good idea to specify a single > "conference time" in absolute terms then specify the rest of the times as > deltas from that. > > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Apr 12 23:08:21 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 XAA03375 for ; Mon, 12 Apr 2004 23:08:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEHC-0004JV-UT for xcon-archive@odin.ietf.org; Mon, 12 Apr 2004 23:07:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D37sUc016577 for xcon-archive@odin.ietf.org; Mon, 12 Apr 2004 23:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEHC-0004JI-MM for xcon-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 23:07: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 XAA03362 for ; Mon, 12 Apr 2004 23:07:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEH6-0005wr-00 for xcon-web-archive@ietf.org; Mon, 12 Apr 2004 23:07:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEEx-0005sY-00 for xcon-web-archive@ietf.org; Mon, 12 Apr 2004 23:05:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDEDQ-0005nr-00 for xcon-web-archive@ietf.org; Mon, 12 Apr 2004 23:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEDQ-0003ny-G6; Mon, 12 Apr 2004 23:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDED3-0003nI-LL for xcon@optimus.ietf.org; Mon, 12 Apr 2004 23:03: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 XAA03198 for ; Mon, 12 Apr 2004 23:03:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDECy-0005mt-00 for xcon@ietf.org; Mon, 12 Apr 2004 23:03:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEAf-0005f0-00 for xcon@ietf.org; Mon, 12 Apr 2004 23:01:10 -0400 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDE8J-0005U8-00 for xcon@ietf.org; Mon, 12 Apr 2004 22:58:44 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 13 Apr 2004 14:06:12 +0530 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3D2viZE017798; Mon, 12 Apr 2004 19:57:45 -0700 (PDT) Received: from [128.107.170.99] ([128.107.170.99]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOB25248; Mon, 12 Apr 2004 19:58:02 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 12 Apr 2004 19:57:59 -0700 Subject: Re: [XCON] Stop the Start Time From: Cullen Jennings To: Roni Even , XCON-IETF Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 Agree, but we have a scope question. Is CPCP a protocol used to request reservations for meetings, in which case it probably needs some more requirements, or is it just describing the policy of a meeting scheduled in another system. If it's the later, I'm not sure it needs to know the "expect duration" of the conference but I agree that is very different than the "maximum duration". I'd love to get more people view on what the scope of CPCP is for doing reservations. Cullen On 4/8/04 1:21 AM, "Even, Roni" wrote: > Cullen, > Extending is not the same as the must not mix after time. For the initial > length of the conference, resources are guaranteed while extension is > typically on best effort. So these should be different parameters > Roni > > ************************************* > Roni Even > VP Product Planning > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, April 07, 2004 8:27 PM > To: Roni Even; XCON-IETF > Subject: Re: [XCON] Stop the Start Time > > > > Hmm, well I don't know if I get the difference between time requirements and > general requirements but I don't know if it is important as long as we agree > on what the requirements are. > > If the conference can be automatically extended, then the "must not mix > after time" is infinite. If the the conference is manually extended, then it > is just that the "must not mix after time" has been modified and the policy > of who is allowed to change this conference parameter is the same policy > problem of who is allowed to change anything else in CPCP. > > Cullen > > > On 4/7/04 12:24 AM, "Even, Roni" wrote: > >> Cullen, >> >> "Need to be able to specify if mixing happens before a participant with > some >> specialized role joins and if >> it continues after all the participants with some specialized role leave. >> This is to support conference where mixing does not happen when the owner > of >> the conference is not present." >> >> These are not time requirement, they apply to conference in general. A >> similar requirement is to be able to specify if the conference can be >> extended (manually or automatic) >> >> Roni >> >> >> ************************************* >> Roni Even >> VP Product Planning >> Polycom Israel >> >> Tel: +972-3-9251200 >> Cell: +972-55-481099 >> email:roni.even@polycom.co.il >> ******************************************* >> >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, April 06, 2004 7:51 PM >> To: Cullen Jennings; XCON-IETF >> Subject: [XCON] Stop the Start Time >> >> >> >> Requirements related to time and conferences. >> >> Need to be able to specify what time the dial begins. Need to be able to >> specify time that media mixing will not happen before and also time that >> mixing will not continue after. These times are optional. All times are in >> GMT and there is no need for time zones. Need to be able to specify if >> mixing happens before a participant with some specialized role joins and > if >> it continues after all the participants with some specialized role leave. >> This is to support conference where mixing does not happen when the owner > of >> the conference is not present. A resolution of 1 second is adequate for > all >> these times. >> >> A a side note, I feel that start and stop time are a confusing term to use >> for any of the times above. It might be a good idea to specify a single >> "conference time" in absolute terms then specify the rest of the times as >> deltas from that. >> >> >> >> >> >> >> _______________________________________________ >> 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 Tue Apr 13 01:19:40 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 BAA07016 for ; Tue, 13 Apr 2004 01:19: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 1BDGKF-0004Fp-BS for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 01:19:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D5JBrT016349 for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 01:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDGKF-0004Fc-6s for xcon-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 01:19: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 BAA07004 for ; Tue, 13 Apr 2004 01:19:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDGKA-00032x-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 01:19:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDGIq-000301-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 01:17:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDGIA-0002ye-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 01:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDGI9-0004At-9r; Tue, 13 Apr 2004 01:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDGHs-00049R-KS for xcon@optimus.ietf.org; Tue, 13 Apr 2004 01:16: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 BAA06983 for ; Tue, 13 Apr 2004 01:16:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDGHo-0002xo-00 for xcon@ietf.org; Tue, 13 Apr 2004 01:16:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDGFr-0002v6-00 for xcon@ietf.org; Tue, 13 Apr 2004 01:14:40 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BDGF5-0002rV-00 for xcon@ietf.org; Tue, 13 Apr 2004 01:13:52 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <2S9MHKAS>; Tue, 13 Apr 2004 08:13:09 +0300 Message-ID: From: "Even, Roni" To: "'Cullen Jennings'" , XCON-IETF Subject: RE: [XCON] Stop the Start Time Date: Tue, 13 Apr 2004 08:13:03 +0300 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 I think that the view was that we are not addressing reservations. If that is the case I think that the document should explicitly say that those parameters should be used for best efforts or as information for the participants, otherwise having infinite times may not be a good idea. Roni Even -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, April 13, 2004 5:58 AM To: Roni Even; XCON-IETF Subject: Re: [XCON] Stop the Start Time Agree, but we have a scope question. Is CPCP a protocol used to request reservations for meetings, in which case it probably needs some more requirements, or is it just describing the policy of a meeting scheduled in another system. If it's the later, I'm not sure it needs to know the "expect duration" of the conference but I agree that is very different than the "maximum duration". I'd love to get more people view on what the scope of CPCP is for doing reservations. Cullen On 4/8/04 1:21 AM, "Even, Roni" wrote: > Cullen, > Extending is not the same as the must not mix after time. For the initial > length of the conference, resources are guaranteed while extension is > typically on best effort. So these should be different parameters > Roni > > ************************************* > Roni Even > VP Product Planning > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, April 07, 2004 8:27 PM > To: Roni Even; XCON-IETF > Subject: Re: [XCON] Stop the Start Time > > > > Hmm, well I don't know if I get the difference between time requirements and > general requirements but I don't know if it is important as long as we agree > on what the requirements are. > > If the conference can be automatically extended, then the "must not mix > after time" is infinite. If the the conference is manually extended, then it > is just that the "must not mix after time" has been modified and the policy > of who is allowed to change this conference parameter is the same policy > problem of who is allowed to change anything else in CPCP. > > Cullen > > > On 4/7/04 12:24 AM, "Even, Roni" wrote: > >> Cullen, >> >> "Need to be able to specify if mixing happens before a participant with > some >> specialized role joins and if >> it continues after all the participants with some specialized role leave. >> This is to support conference where mixing does not happen when the owner > of >> the conference is not present." >> >> These are not time requirement, they apply to conference in general. A >> similar requirement is to be able to specify if the conference can be >> extended (manually or automatic) >> >> Roni >> >> >> ************************************* >> Roni Even >> VP Product Planning >> Polycom Israel >> >> Tel: +972-3-9251200 >> Cell: +972-55-481099 >> email:roni.even@polycom.co.il >> ******************************************* >> >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, April 06, 2004 7:51 PM >> To: Cullen Jennings; XCON-IETF >> Subject: [XCON] Stop the Start Time >> >> >> >> Requirements related to time and conferences. >> >> Need to be able to specify what time the dial begins. Need to be able to >> specify time that media mixing will not happen before and also time that >> mixing will not continue after. These times are optional. All times are in >> GMT and there is no need for time zones. Need to be able to specify if >> mixing happens before a participant with some specialized role joins and > if >> it continues after all the participants with some specialized role leave. >> This is to support conference where mixing does not happen when the owner > of >> the conference is not present. A resolution of 1 second is adequate for > all >> these times. >> >> A a side note, I feel that start and stop time are a confusing term to use >> for any of the times above. It might be a good idea to specify a single >> "conference time" in absolute terms then specify the rest of the times as >> deltas from that. >> >> >> >> >> >> >> _______________________________________________ >> 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 Tue Apr 13 03:40:27 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 DAA26267 for ; Tue, 13 Apr 2004 03:40: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 1BDIWU-0008ST-Ne for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 03:39:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7dwhU032509 for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 03:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIWU-0008SG-EI for xcon-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 03:39:58 -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 DAA26222 for ; Tue, 13 Apr 2004 03:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDIWR-0002JD-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDIMS-0001lI-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:29:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDIIU-0001EJ-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:25:31 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDI2e-0000GN-NR for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:09:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI2X-0003L7-DH; Tue, 13 Apr 2004 03:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI1m-0003F4-5r for xcon@optimus.ietf.org; Tue, 13 Apr 2004 03:08: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 DAA24778 for ; Tue, 13 Apr 2004 03:08:11 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI1h-0000Bf-00 for xcon@ietf.org; Tue, 13 Apr 2004 03:08:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHzh-00000Z-00 for xcon@ietf.org; Tue, 13 Apr 2004 03:06:05 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BDHy5-0007hH-00 for xcon@ietf.org; Tue, 13 Apr 2004 03:04:25 -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 i3D73kn14265; Tue, 13 Apr 2004 10:03:46 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:03:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3D73J1r011447; Tue, 13 Apr 2004 10:03:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00OWfLI9; Tue, 13 Apr 2004 10:03:18 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 i3D73Es13038; Tue, 13 Apr 2004 10:03:14 +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); Tue, 13 Apr 2004 10:03: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: Tue, 13 Apr 2004 10:03:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D9@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBmTH5J087aTXyyKk+jeZNgGQFJO0XQAAAXe0A= To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:03:14.0031 (UTC) FILETIME=[6383DFF0:01C42125] Content-Transfer-Encoding: quoted-printable Subject: [XCON] RE: Joint Interim Meeting Mon May 24 - Wed May 26 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 One small correction: Rooms will be help until 3rd May. Thanks, Hisham > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 13.April.2004 10:01 > To: 'ext Rohan Mahy'; 'xcon@ietf.org' > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Here is the hotel information: >=20 > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 >=20 > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB >=20 > There are 50 rooms booked for this event at the rate of $99=20 > per night (from Sunday 23rd until Wednesday 26th). These=20 > rooms will be held until 3th May, so please reserve your room=20 > on or before that date. >=20 > You can reserve online or by telephone using the Group Code: NONOKA >=20 > Also, please use the links that Rohan provided to confirm=20 > your attendance. This will aid us in determining the catering=20 > requirements. Here is the link again: >=20 > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > interim]yes >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 06.April.2004 20:54 > > To: 'xcon@ietf.org' > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > > Rohan Mahy; Alan Johnston; Adam Roach > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Hello All, > >=20 > > Please mark your calendars. > >=20 > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > SIMPLE, and =20 > > XCON WGs. > > Nokia has generously agreed to host the event either at their=20 > > offices =20 > > near Boston or in a neighboring hotel during the week of May 24. > >=20 > > Please reserve the following dates for the WGs that you are=20 > > interested =20 > > in: > > Monday May 24 SIP and SIPPING tentatively 9 am start > > Tuesday May 25 SIMPLE All day > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > can catch =20 > > flights. > > (the actual agenda is subject to change, including the dates=20 > > of various =20 > > WG meetings). > >=20 > > There will be no fee, however please let Hisham and myself=20 > > know if you =20 > > are planning to attend by clicking on the Yes or Maybe links below: > >=20 > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > mailto:rohan@cisco.com?=20 > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > >=20 > > Wireless will be provided. As usual, I will be making=20 > > T-shirts. If you =20 > > are interested in buying one, please send your shirt size to me. > >=20 > > More details on the agenda and hotel accommodations will be=20 > > forthcoming =20 > > shortly. > >=20 > > thanks, > > -rohan > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Apr 13 03:41:42 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 DAA26359 for ; Tue, 13 Apr 2004 03:41: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 1BDIXh-000062-M1 for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 03:41:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D7fDZl000366 for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 03:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDIXf-00005e-Ct for xcon-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 03:41: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 DAA26327 for ; Tue, 13 Apr 2004 03:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDIXb-0002Mv-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:41:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDIN5-0001oM-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:30:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDIIe-0001Ev-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:25:40 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDI1d-0000EP-8V for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 03:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDI1Z-00039L-1W; Tue, 13 Apr 2004 03: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 1BDI1W-00038A-EJ for xcon@optimus.ietf.org; Tue, 13 Apr 2004 03:07:58 -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 DAA24764 for ; Tue, 13 Apr 2004 03:07:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDI1R-00009L-00 for xcon@ietf.org; Tue, 13 Apr 2004 03:07:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDHzR-0007nZ-00 for xcon@ietf.org; Tue, 13 Apr 2004 03:05:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDHxZ-0007gZ-00 for xcon@ietf.org; Tue, 13 Apr 2004 03:03:54 -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 i3D735H27843; Tue, 13 Apr 2004 10:03:05 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 10:00:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3D70fHg027419; Tue, 13 Apr 2004 10:00:41 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00It01I6; Tue, 13 Apr 2004 10:00:39 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 i3D70dF14290; Tue, 13 Apr 2004 10:00:39 +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); Tue, 13 Apr 2004 10:00:39 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 10:00:37 +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, 13 Apr 2004 10:00:38 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978D5@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBmTH5J087aTXyyKk+jeZNgGQFJO0XQ To: , Cc: , , , , , , , X-OriginalArrivalTime: 13 Apr 2004 07:00:37.0486 (UTC) FILETIME=[063500E0:01C42125] Content-Transfer-Encoding: quoted-printable Subject: [XCON] RE: Joint Interim Meeting Mon May 24 - Wed May 26 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 Here is the hotel information: Renaissance Boston Hotel Bedford 44 Middlesex Turnpike Bedford, MA 01730 USA Phone: 1 781-275-5500 Fax: 1 781-275-3042 http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB There are 50 rooms booked for this event at the rate of $99 per night = (from Sunday 23rd until Wednesday 26th). These rooms will be held until = 3th May, so please reserve your room on or before that date. You can reserve online or by telephone using the Group Code: NONOKA Also, please use the links that Rohan provided to confirm your = attendance. This will aid us in determining the catering requirements. = Here is the link again: mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim= ]yes Thanks, Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 06.April.2004 20:54 > To: 'xcon@ietf.org' > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo Camarillo; > Rohan Mahy; Alan Johnston; Adam Roach > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > Hello All, >=20 > Please mark your calendars. >=20 > I'd like to announce a joint interim of the SIP, SIPPING,=20 > SIMPLE, and =20 > XCON WGs. > Nokia has generously agreed to host the event either at their=20 > offices =20 > near Boston or in a neighboring hotel during the week of May 24. >=20 > Please reserve the following dates for the WGs that you are=20 > interested =20 > in: > Monday May 24 SIP and SIPPING tentatively 9 am start > Tuesday May 25 SIMPLE All day > Wednesday May 26 XCON tentatively finish at 4pm so folks can catch =20 > flights. > (the actual agenda is subject to change, including the dates=20 > of various =20 > WG meetings). >=20 > There will be no fee, however please let Hisham and myself=20 > know if you =20 > are planning to attend by clicking on the Yes or Maybe links below: >=20 > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > mailto:rohan@cisco.com?=20 > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe >=20 > Wireless will be provided. As usual, I will be making=20 > T-shirts. If you =20 > are interested in buying one, please send your shirt size to me. >=20 > More details on the agenda and hotel accommodations will be=20 > forthcoming =20 > shortly. >=20 > thanks, > -rohan >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Apr 13 09:06: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 JAA10033 for ; Tue, 13 Apr 2004 09:06: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 1BDNbm-0003l1-Np for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 09:05:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DD5ksw014443 for xcon-archive@odin.ietf.org; Tue, 13 Apr 2004 09:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNbm-0003kr-Ib for xcon-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 09:05: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 JAA09949 for ; Tue, 13 Apr 2004 09:05:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNbk-00006H-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 09:05:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNZr-0007ef-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 09:03:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDNYK-0007VU-00 for xcon-web-archive@ietf.org; Tue, 13 Apr 2004 09:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNYJ-0003U1-4H; Tue, 13 Apr 2004 09:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDNXd-0003AL-Q9 for xcon@optimus.ietf.org; Tue, 13 Apr 2004 09:01:29 -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 JAA09736 for ; Tue, 13 Apr 2004 09:01:27 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDNXb-0007Qz-00 for xcon@ietf.org; Tue, 13 Apr 2004 09:01:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDNWl-0007M3-00 for xcon@ietf.org; Tue, 13 Apr 2004 09:00:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDNVW-0007Gr-00 for xcon@ietf.org; Tue, 13 Apr 2004 08:59:18 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DCxFH23373 for ; Tue, 13 Apr 2004 15:59:15 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 15:59:10 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3DCxAuR011453 for ; Tue, 13 Apr 2004 15:59:10 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00pD9UdM; Tue, 13 Apr 2004 15:59:07 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 i3DCx7F01965 for ; Tue, 13 Apr 2004 15:59:07 +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); Tue, 13 Apr 2004 15:59: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 Subject: RE: [XCON] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Date: Tue, 13 Apr 2004 15:58:59 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017978E0@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBmTH5J087aTXyyKk+jeZNgGQFJO0XQAAAXe0AADGvHwA== To: X-OriginalArrivalTime: 13 Apr 2004 12:59:00.0648 (UTC) FILETIME=[17172280:01C42157] 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.7 required=5.0 tests=AWL,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It was pointed out to me that the Group Code for booking was incorrect. = Here is the correct Group Code: NOKNOKA. Apologies for the inconvenience. Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 13.April.2004 10:03 > To: rohan@cisco.com; xcon@ietf.org > Cc: dean.willis@softarmor.com; mankin@psg.com; rjsparks@nostrum.com; > jon.peterson@neustar.biz; hardie@qualcomm.com; > Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; > adam@dynamicsoft.com > Subject: [XCON] RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > One small correction: >=20 > Rooms will be help until 3rd May. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > Sent: 13.April.2004 10:01 > > To: 'ext Rohan Mahy'; 'xcon@ietf.org' > > Cc: Dean Willis; Allison Mankin; Robert Sparks; John Peterson; Ted > > Hardie; Gonzalo Camarillo; Alan Johnston; Adam Roach > > Subject: RE: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Here is the hotel information: > >=20 > > Renaissance Boston Hotel Bedford > > 44 Middlesex Turnpike Bedford, MA 01730 USA > > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > >=20 > > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB > >=20 > > There are 50 rooms booked for this event at the rate of $99=20 > > per night (from Sunday 23rd until Wednesday 26th). These=20 > > rooms will be held until 3th May, so please reserve your room=20 > > on or before that date. > >=20 > > You can reserve online or by telephone using the Group Code: NONOKA > >=20 > > Also, please use the links that Rohan provided to confirm=20 > > your attendance. This will aid us in determining the catering=20 > > requirements. Here is the link again: > >=20 > > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > > interim]yes > >=20 > > Thanks, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: 06.April.2004 20:54 > > > To: 'xcon@ietf.org' > > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo=20 > Camarillo; > > > Rohan Mahy; Alan Johnston; Adam Roach > > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > > >=20 > > >=20 > > > Hello All, > > >=20 > > > Please mark your calendars. > > >=20 > > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > > SIMPLE, and =20 > > > XCON WGs. > > > Nokia has generously agreed to host the event either at their=20 > > > offices =20 > > > near Boston or in a neighboring hotel during the week of May 24. > > >=20 > > > Please reserve the following dates for the WGs that you are=20 > > > interested =20 > > > in: > > > Monday May 24 SIP and SIPPING tentatively 9 am start > > > Tuesday May 25 SIMPLE All day > > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > > can catch =20 > > > flights. > > > (the actual agenda is subject to change, including the dates=20 > > > of various =20 > > > WG meetings). > > >=20 > > > There will be no fee, however please let Hisham and myself=20 > > > know if you =20 > > > are planning to attend by clicking on the Yes or Maybe=20 > links below: > > >=20 > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > > >=20 > > > Wireless will be provided. As usual, I will be making=20 > > > T-shirts. If you =20 > > > are interested in buying one, please send your shirt size to me. > > >=20 > > > More details on the agenda and hotel accommodations will be=20 > > > forthcoming =20 > > > shortly. > > >=20 > > > thanks, > > > -rohan > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Apr 16 06:33:42 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 GAA28294 for ; Fri, 16 Apr 2004 06:33: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 1BEQas-0001h5-U1 for xcon-archive@odin.ietf.org; Fri, 16 Apr 2004 06:29:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GATAJ5006507 for xcon-archive@odin.ietf.org; Fri, 16 Apr 2004 06:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQZn-0001Sv-Rs for xcon-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 06:28: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 GAA28012 for ; Fri, 16 Apr 2004 06:27: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 1BEQZj-0007Bu-Tl for xcon-web-archive@ietf.org; Fri, 16 Apr 2004 06:27:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQYs-00076e-00 for xcon-web-archive@ietf.org; Fri, 16 Apr 2004 06:27:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEQY8-000716-00 for xcon-web-archive@ietf.org; Fri, 16 Apr 2004 06:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQUv-0000JK-BP; Fri, 16 Apr 2004 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQOR-0007rQ-GN for xcon@optimus.ietf.org; Fri, 16 Apr 2004 06:16: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 GAA27540 for ; Fri, 16 Apr 2004 06:16: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 1BEQON-0005wa-Ir for xcon@ietf.org; Fri, 16 Apr 2004 06:16:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQNM-0005rb-00 for xcon@ietf.org; Fri, 16 Apr 2004 06:15:13 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BEQN2-0005mP-00 for xcon@ietf.org; Fri, 16 Apr 2004 06:14:52 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GAE9H28319; Fri, 16 Apr 2004 13:14:09 +0300 (EET DST) X-Scanned: Fri, 16 Apr 2004 13:14:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3GAE1wv032493; Fri, 16 Apr 2004 13:14:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00jzy26V; Fri, 16 Apr 2004 13:13:59 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 i3GADns21447; Fri, 16 Apr 2004 13:13:49 +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); Fri, 16 Apr 2004 13:13: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: Fri, 16 Apr 2004 13:13:00 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179791B@esebe019.ntc.nokia.com> Thread-Topic: CPCP Reqs and time-related requirements Thread-Index: AcQjmi+nOVrDvaJFRUqCsjOXEwiufwAAHI6Q To: , , , , Cc: , X-OriginalArrivalTime: 16 Apr 2004 10:13:00.0541 (UTC) FILETIME=[65A4AAD0:01C4239B] Content-Transfer-Encoding: quoted-printable Subject: [XCON] RE: CPCP Reqs and time-related requirements Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 [moving to the mailing list] > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 16.April.2004 13:00 > To: Koskelainen Petri (Nokia-NRC/Tampere); fluffy@cisco.com; > rohan@cisco.com; adam@dynamicsoft.com; Even, Roni > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); alan.johnston@mci.com > Subject: RE: CPCP Reqs and time-related requirements >=20 >=20 >=20 > Hi, > In general I think you are going to a mine field with the=20 > time issue since > the majority wants it so go ahead. > Now for comments >=20 > 1. I think that there should be a requirement that states=20 > that it must be > possible to change the end time after the conference has started. Yes, we had the requirement but it looks like Petri forgot to add it in = here (You can notice that REQ X5 is missing from the list below. >=20 > 2. In general - Do you think that media mixing end-time is=20 > separate from the > conference end-time. If not how are they related. Do you specify the > conference length by the mixing time. We are not defining conference end-time. That was agreed already due to = resource reservation issues. What the conference policy carries is the = conference media mixing end-time. >=20 > 3. I think that there should be some text explaining if the=20 > times are for > resource reservation or if it is up to the application. I=20 > think that the > consensus was that it is not resource reservation and it is up to the > application to decide if it is or not. Agreed.=20 Thanks, Hisham >=20 >=20 > Roni >=20 > ************************************* > Roni Even > VP Product Planning > Polycom Israel >=20 > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >=20 >=20 > -----Original Message----- > From: petri.koskelainen@nokia.com [mailto:petri.koskelainen@nokia.com] > Sent: Friday, April 16, 2004 12:38 PM > To: fluffy@cisco.com; rohan@cisco.com; adam@dynamicsoft.com; > roni.even@polycom.co.il > Cc: hisham.khartabil@nokia.com; alan.johnston@mci.com > Subject: CPCP Reqs and time-related requirements >=20 >=20 > Hi, >=20 > Based on the feedback, list discussion, and meeting minutes we came up > with the following proposal with Hisham. Please comment.. >=20 > New time related requirements: >=20 >=20 > REQ X1: It MUST be possible to define the time when media=20 > mixing may start > ("don't-mix-before-time") and=20 > stop ("cannot-continue-after") operating in the conference. >=20 > REQ X2: It MUST be possible to define the time after which=20 > users are allowed > to join the conference.=20 >=20 > REQ X3: It MUST be possible to define the time after which=20 > new users are not > allowed to join=20 > the conference anymore=20 >=20 > REQ X4: It MUST be possible to define the time when users or=20 > resources on > the dial-out=20 > list are invited to join the conference. >=20 > REQ X6: It MUST be possible to indicate key participants >=20 > REQ X7a: It MUST be possible to define when media mixing=20 > starts based on the > latter of the mixing start time, and the time the first=20 > participant arrives > REQ X7b: It MUST be possible to define when media mixing=20 > starts based on the > latter of the mixing start time, and the time the first key=20 > participant > arrives >=20 > REQ X8a: It MUST be possible to define when media mixing=20 > stops based on the > earlier of the mixing stop time, and the time the last=20 > participant leaves > the conference > REQ X8b: It MUST be possible to define when media mixing=20 > stops based on the > earlier of the mixing stop time, and the time the last key participant > leaves > REQ X8c: It MUST be possible to define when media mixing=20 > stops based on the > time only. >=20 >=20 > REQ X9: It MUST be possible to define that the users and=20 > resources on the > dial-out list are invited > only after first key participant has joined. > Note: This parameter, if set, overrides the time defined by X4. >=20 >=20 >=20 > -- > Petri > > -----Original Message----- > > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 16 April, 2004 00:40 > > To: Rohan Mahy; Adam Roach > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); alan.johnston@mci.com; > > Koskelainen Petri (Nokia-NRC/Tampere) > > Subject: Re: CPCP Reqs > >=20 > >=20 > >=20 > > I think I sent text too. > >=20 > > On 4/1/04 12:44 PM, "Rohan Mahy" wrote: > >=20 > > > I sent this to Eric Burger and Hisham..... > > >=20 > > >> You have a collection of "startPolicies". a few of these=20 > > enumerated > > >> in CPCP need to include: > > >>=20 > > >> 1. cantMixBeforeTime (a time before which no mixing=20 > could possibly > > >> occur--mixing could begin later or not at all) it could be=20 > > expressed a > > >> delta, in gmt, as now, or never > > >>=20 > > >> 2. dialoutTime (the time when you call participants into the > > >> conference. it could be expressed as a delta, in gmt, as now, as > > >> never, and "at usage start" > > >>=20 > > >> You could also add to CPCP a way to define when usage of the > > >> conference begins > > >>=20 > > >> 3. startUsagePolicy describes how the conference server=20 > determines > > >> that a conference is being used for the first time. =20 > when anyn(n) > > >> participants join, when allOf(list) listed participants=20 > join, when > > >> anynof(n,list) (any of the listed participants) indicates a > > >> sufficient quorum. > > >>=20 > > >> You also need a collection of "destroyPolicies". At least one of > > >> these is: > > >>=20 > > >> 1. cantContinuePast (a time after which no more mixing=20 > > could possibly > > >> occur) which could be expressed as a delta (from now),=20 > > gmt, now, never > > >>=20 > > >> optionally you could also have > > >>=20 > > >> 2. autoDestroyPolicy describes how the conference server=20 > > determines it > > >> can reclaim and automatically destroy a conference that is=20 > > no longer > > >> interesting. This could be expressed as never, at an=20 > > explicit time, > > >> when there are minparticipants(n) or =20 > > minlistedparticipants(n, > > >> list), or minparticipantswithrole(n, rolelist), or > > >> minparticipantswithproperties(n, propertylist) > > >>=20 > > >>=20 > > >> Notes: "delta" is always a number of time units (ex: seconds, > > >> milliseconds) from now. > > >> Observation on dialoutTime: If you have 5 dialout users=20 > > and two are > > >> keyparticipants, how do you do that. answer=20 > > startpolicy-dialouttime > > >> is anything other than atstart. individual dial-out uris have a > > >> boolean policy knob, waitforstart which is set on all the non-key > > >> dialout participants > > >=20 > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Apr 21 22:52:38 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 WAA11951 for ; Wed, 21 Apr 2004 22:52: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 1BGUFA-0000ou-FH for xcon-archive@odin.ietf.org; Wed, 21 Apr 2004 22:47:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M2lG8A003138 for xcon-archive@odin.ietf.org; Wed, 21 Apr 2004 22: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 1BGUAY-0007Fh-9J for xcon-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 22:42: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 WAA11484 for ; Wed, 21 Apr 2004 22:42: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 1BGUAU-0006vQ-UY for xcon-web-archive@ietf.org; Wed, 21 Apr 2004 22:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGU9b-0006k7-00 for xcon-web-archive@ietf.org; Wed, 21 Apr 2004 22:41:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGU8y-0006Yl-00 for xcon-web-archive@ietf.org; Wed, 21 Apr 2004 22:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGU1N-0002nr-0A; Wed, 21 Apr 2004 22:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTy0-0000iK-Sf for xcon@optimus.ietf.org; Wed, 21 Apr 2004 22:29: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 WAA10904 for ; Wed, 21 Apr 2004 22:29: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 1BGTxx-0004JC-I2 for xcon@ietf.org; Wed, 21 Apr 2004 22:29:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGTwr-00047E-00 for xcon@ietf.org; Wed, 21 Apr 2004 22:28:22 -0400 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGTvu-0003ks-00 for xcon@ietf.org; Wed, 21 Apr 2004 22:27:22 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42811.14CEE538" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 21 Apr 2004 19:25:30 -0700 Message-ID: <6677B3346233B94EBB11C060935101202669BF@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: CPCP Originator URI Thread-Index: AcQoEU2Or7hoA0q6R5utxLSs68IQFQ== From: "Jani, Manish" To: Subject: [XCON] CPCP Originator URI 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=HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42811.14CEE538 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How is URI of the originator who made CPCP request is constructed? =20 Consider following example: =20 If an application want to specify additional privilege to modify ACL, say RIGHT_TO_MODIFY_ACL then Policy would like=20 sip:Alice@example.com RIGHT_TO_MODIFY_ACL =20 Now when Alice wants to modify ACL, would make CPCP request like=20 PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference/ACL/ACL-target-URI HTTP/1.1 Content-Type:text/plain sip:bob@example.com How would CPCP implementation find out the URI of the originator, in this case, sip:Alice@example.com in order to determine if the originator is allowed to modify ACL? =20 - Option 1: Can get User name (Alice) and domain name (example.com) and put keyword "sip:" in front (sip:Alice@example.com). This is not a clean way. Also this will break if http request contains IP address instead of domain name. - Option 2: Specify in http request by name value pair. =20 Thanks, Manish =20 =20 =20 ------_=_NextPart_001_01C42811.14CEE538 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
How is = URI of the=20 originator who made CPCP request is constructed?
 
Consider following=20 example:
 
If an=20 application want to specify additional privilege to modify ACL, say=20 RIGHT_TO_MODIFY_ACL then Policy would like
<PCL-target>
   =20 <PCL-target-URI>sip:Alice@example.com</PCL-target-URI>
&nb= sp;  =20 <Privileges>RIGHT_TO_MODIFY_ACL</Privileges>
</PCL-targ= et>
 
=
Now = when Alice wants=20 to modify ACL, would make CPCP request like
      PUT=20 http://xcap.example.com/services/conferences/users/Alice/conference.xml?<= BR>        =20 Conference/ACL/ACL-target-URI=20 HTTP/1.1
        =20 Content-Type:text/plain

      = <ACL-target-URI=20 Access-type=3D"Expelled">sip:bob@example.com</ACL-target-URI>
How = would CPCP=20 implementation find out the URI of the originator, in this case,=20 sip:Alice@example.com in order to determine if the originator is = allowed to=20 modify ACL?
 
- = Option 1: Can get=20 User name (Alice) and domain name (example.com) and put keyword "sip:" = in front=20 (sip:Alice@example.com). This is not a clean way. Also this will break = if http=20 request contains IP address instead of domain name.
- = Option 2: Specify=20 in http request by name value pair.
 
Thanks,
Manish
 
 
 
------_=_NextPart_001_01C42811.14CEE538-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Apr 22 03:40:40 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 DAA09210 for ; Thu, 22 Apr 2004 03:40: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 1BGYnP-000316-8J for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 03:38:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M7ctNI011592 for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 03:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYZn-0004vY-W7 for xcon-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 03:24: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 DAA08494 for ; Thu, 22 Apr 2004 03:24: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 1BGYZj-0003i1-WA for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 03:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYYh-0003Q6-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 03:23:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGYXg-0003BC-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 03:22:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYKd-0006LJ-AY; Thu, 22 Apr 2004 03:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYIG-0004DC-It for xcon@optimus.ietf.org; Thu, 22 Apr 2004 03:06: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 DAA07189 for ; Thu, 22 Apr 2004 03:06:40 -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 1BGYIC-00076z-II for xcon@ietf.org; Thu, 22 Apr 2004 03:06:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYH7-0006qX-00 for xcon@ietf.org; Thu, 22 Apr 2004 03:05:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGYG6-0006V3-00 for xcon@ietf.org; Thu, 22 Apr 2004 03:04:31 -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 i3M74N303630; Thu, 22 Apr 2004 10:04:23 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 10:04:00 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3M740pL023518; Thu, 22 Apr 2004 10:04:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 003NH4Je; Thu, 22 Apr 2004 10:03:58 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 i3M73Vs28186; Thu, 22 Apr 2004 10:03:31 +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, 22 Apr 2004 10:00:29 +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_01C42837.7ED22B04" Subject: RE: [XCON] CPCP Originator URI Date: Thu, 22 Apr 2004 10:00:28 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797971@esebe019.ntc.nokia.com> Thread-Topic: CPCP Originator URI Thread-Index: AcQoEU2Or7hoA0q6R5utxLSs68IQFQAJZ0xg To: , X-OriginalArrivalTime: 22 Apr 2004 07:00:29.0974 (UTC) FILETIME=[7F728360:01C42837] 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.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42837.7ED22B04 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The privilege you talk about will not be handled this way. But in any = case, the conference policy server will need to assert the identity of = the user using, for example, HTTP digest. It can then map it to the sip = address. =20 Regards, Hisham -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext = Jani, Manish Sent: 22.April.2004 05:26 To: xcon@ietf.org Subject: [XCON] CPCP Originator URI How is URI of the originator who made CPCP request is constructed? =20 Consider following example: =20 If an application want to specify additional privilege to modify ACL, = say RIGHT_TO_MODIFY_ACL then Policy would like=20 sip:Alice@example.com RIGHT_TO_MODIFY_ACL =20 Now when Alice wants to modify ACL, would make CPCP request like=20 PUT = http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference/ACL/ACL-target-URI HTTP/1.1 Content-Type:text/plain sip:bob@example.com How would CPCP implementation find out the URI of the originator, in = this case, sip:Alice@example.com in order to determine if the originator = is allowed to modify ACL? =20 - Option 1: Can get User name (Alice) and domain name (example.com) and = put keyword "sip:" in front (sip:Alice@example.com). This is not a clean = way. Also this will break if http request contains IP address instead of = domain name. - Option 2: Specify in http request by name value pair. =20 Thanks, Manish =20 =20 =20 ------_=_NextPart_001_01C42837.7ED22B04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
The=20 privilege you talk about will not be handled this way. But in any case, = the=20 conference policy server will need to assert the identity of the user = using, for=20 example, HTTP digest. It can then map it to the sip=20 address.
 
Regards,
Hisham
-----Original Message-----
From: = xcon-admin@ietf.org=20 [mailto:xcon-admin@ietf.org]On Behalf Of ext Jani,=20 Manish
Sent: 22.April.2004 05:26
To:=20 xcon@ietf.org
Subject: [XCON] CPCP Originator=20 URI

How = is URI of the=20 originator who made CPCP request is constructed?
 
Consider following=20 example:
 
If an=20 application want to specify additional privilege to modify ACL, say=20 RIGHT_TO_MODIFY_ACL then Policy would like
<PCL-target>
   =20 = <PCL-target-URI>sip:Alice@example.com</PCL-target-URI>
&nb= sp;  =20 = <Privileges>RIGHT_TO_MODIFY_ACL</Privileges>
</PCL-targ= et>
 
Now = when Alice=20 wants to modify ACL, would make CPCP request like
      PUT=20 = http://xcap.example.com/services/conferences/users/Alice/conference.xml?<= BR>        =20 Conference/ACL/ACL-target-URI=20 HTTP/1.1
        =20 Content-Type:text/plain

     =20 <ACL-target-URI=20 = Access-type=3D"Expelled">sip:bob@example.com</ACL-target-URI>
How = would CPCP=20 implementation find out the URI of the originator, in this case,=20 sip:Alice@example.com in order to determine if the originator is = allowed=20 to modify ACL?
 
- = Option 1: Can=20 get User name (Alice) and domain name (example.com) and put keyword = "sip:" in=20 front (sip:Alice@example.com). This is not a clean way. Also this will = break=20 if http request contains IP address instead of domain=20 name.
- = Option 2:=20 Specify in http request by name value pair.
 
Thanks,
Manish
 
 
 
------_=_NextPart_001_01C42837.7ED22B04-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Apr 22 06:56: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 GAA17595 for ; Thu, 22 Apr 2004 06:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbqe-0003HT-DE for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 06:54:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MAsSuL012606 for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 06:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbp6-0002Mz-AO for xcon-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 06:52: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 GAA17428 for ; Thu, 22 Apr 2004 06:52: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 1BGbp0-0004mj-AN for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 06:52:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGbo9-0004Xs-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 06:51:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGbn7-0004IO-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 06:50:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbkP-0000n3-TV; Thu, 22 Apr 2004 06:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbfO-00070D-Px for xcon@optimus.ietf.org; Thu, 22 Apr 2004 06:42: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 GAA17052 for ; Thu, 22 Apr 2004 06:42: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 1BGbfI-0002Kt-TV for xcon@ietf.org; Thu, 22 Apr 2004 06:42:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGbeK-00025L-00 for xcon@ietf.org; Thu, 22 Apr 2004 06:41:45 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGbdI-0001hr-00 for xcon@ietf.org; Thu, 22 Apr 2004 06:40:40 -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 i3MAecG21111; Thu, 22 Apr 2004 13:40:38 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 13:40:22 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3MAeM98002880; Thu, 22 Apr 2004 13:40:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00SgcW3E; Thu, 22 Apr 2004 13:40:20 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 i3MAe9s14956; Thu, 22 Apr 2004 13:40:09 +0300 (EET DST) Received: from nokia.com ([172.21.81.173]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 13:38:26 +0300 Message-ID: <4087A0A1.3030809@nokia.com> Date: Thu, 22 Apr 2004 13:38:25 +0300 From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: ext Adam Roach CC: "'xcon@ietf.org'" Subject: Re: [XCON] Reminder: FC Reqs last call References: <9ACE0CEE075B494096C86C23878BF85906A404@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9ACE0CEE075B494096C86C23878BF85906A404@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 10:38:26.0393 (UTC) FILETIME=[F199B490:01C42855] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Apologies for late comments. Especially since the chairs did a great job in reminding us about the approaching DL. Shame on me... ;) Cheers, Aki --- * In the Introduction (1st Ch.), 5th para: I wonder if there is something specific in these studies that is to be leveraged? If so, maybe it should be mentioned here. * In the Model (4th Ch.), second para.: In the last sentence, I don't understand the benefit in singling out the case where the floor control server itself processes the floor control requests. Logically, there is still a floor chair, however now it is colocated with the server. * 4th Ch., 4th para: this talks about policy data pertaining to a floor, that is outside the actual floor control protocol. Perhaps we need to explicitly talk about floor control policy here. (It's briefly mentioned in REQ 15, nowhere else.) * In the Integration (Ch. 5), first para: this suggests CPCP take care of setting floor control policy. I'd rather see floor control policy be defined as an independent component (read: document). (Of course, e.g., XCAP could still be used to manipulate it, and it should be linked with a conference policy). However, setting priviledges (who can set up, change, remove floors) might still be good to have as a CPCP feature. * REQ-6: Instead of a SHOULD, I think a MAY is more appropriate. What does a SHOULD mean in requirements anyway... * REQ-13: Should this be a MUST? Of course, I would think the time you spend between requesting the floor and having the floor granted to you implicitly already means "queuing". * REQ-15: As above talks about floor policy descriptions, but maybe this term should be floor control policy, and described in the Model already. * REQ-17: I agree this requirement is important. SInce floors can be used across so many different types of conference applications - ranging from ones where floor operations are time sensitive to ones where they really aren't - we might really be talking about different protocols altogether. For elaborate descriptions in floor requests, you almost want something like email, whereas in simple mutex a much more simple protocol is required. Can the requirements somehow reflect this? I.e., make the smallest common denominator (the latter protocol) MUST, and everything on top a MAY? * REQ-18: This again talks about a priviledge for a conference (e.g., ABLE_TO_SEE_FLOOR). I don't believe current CPCP addresses this. * REQ-19: Same as above, this seems like a conference priviledge that CPCP currently doesn't address. Also, what is the difference with REQ-18? * In Open Issues (Ch. 7): IMO, these privacy preferences aren't necessarily something that the floor requester should indicate; rahter I think they should be set in the floor control policy, and indicated to all participants (i.e., I think it is the conference admin who decides what the privacy settings should be) * Also, REQ-b sounds again like another priviledge in a conference (ABLE_TO_SEE_FLOOR_CHAIR). --- ext Adam Roach wrote: > As a reminder, we are currently conducting a last call > for the Floor Control Requirements document. This last > call period ends in one week. Lacking any comments, the > chairs will request publication as an RFC at that time. > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Apr 22 07:54:04 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 HAA20267 for ; Thu, 22 Apr 2004 07:54:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGckR-0008T0-4T for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 07:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MBq7PG032542 for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 07:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGcfj-0006m8-OB for xcon-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 07:47: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 HAA19937 for ; Thu, 22 Apr 2004 07:47: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 1BGcfd-0002dr-6w for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 07:47:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGceU-0002NE-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 07:45:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGcdx-00028D-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 07:45:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGcXl-0003ww-66; Thu, 22 Apr 2004 07: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 1BGcT1-0001sA-27 for xcon@optimus.ietf.org; Thu, 22 Apr 2004 07:34: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 HAA19245 for ; Thu, 22 Apr 2004 07:34:01 -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 1BGcSu-0007BC-Fj for xcon@ietf.org; Thu, 22 Apr 2004 07:34:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGcRt-0006uU-00 for xcon@ietf.org; Thu, 22 Apr 2004 07:32:58 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BGcRH-0006fn-00 for xcon@ietf.org; Thu, 22 Apr 2004 07:32:20 -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 i3MBWJu23019; Thu, 22 Apr 2004 14:32:19 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 14:31:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3MBVbiA010296; Thu, 22 Apr 2004 14:31:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 008DTjHa; Thu, 22 Apr 2004 14:31:35 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 i3MBVWs17285; Thu, 22 Apr 2004 14:31:32 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 14:31:31 +0300 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 14:31:30 +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] Reminder: FC Reqs last call Date: Thu, 22 Apr 2004 14:31:30 +0300 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E9BD75@trebe004.europe.nokia.com> Thread-Topic: [XCON] Reminder: FC Reqs last call Thread-Index: AcQoWF6/fe9Xjd+rSaO2XeoCWdJilgAAIsJw To: , Cc: X-OriginalArrivalTime: 22 Apr 2004 11:31:30.0585 (UTC) FILETIME=[5B86D890:01C4285D] 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, Thanks for the comments. See inline.. > * In the Introduction (1st Ch.), 5th para: I wonder if there is=20 > something specific in these studies that is to be leveraged? If so,=20 > maybe it should be mentioned here. We'll change the wording (the idea was just to mention that this work is largely based on the earlier work). =20 > * In the Model (4th Ch.), second para.: In the last sentence, I don't=20 > understand the benefit in singling out the case where the=20 > floor control server itself processes the floor control requests.=20 > Logically, there is still a floor chair, however now it is colocated = with the server. There isn't always a chair. Floor policy (set via CPCP) may define = different policies=20 (say, fcfs) in which the server itself can take the decision.=20 =20 > * 4th Ch., 4th para: this talks about policy data pertaining=20 > to a floor, that is outside the actual floor control protocol.=20 > Perhaps we need to explicitly talk about floor control policy here.=20 > (It's briefly mentioned in REQ 15, nowhere else.) Sections 4 and 5 talk about this, but perhaps the wording is not best possibly and this issue can be further clarified. >=20 > * In the Integration (Ch. 5), first para: this suggests CPCP=20 > take care of setting floor control policy.=20 Yes, this is correct. CPCP (or whatever sets the conf policy) sets the = floor policy. > I'd rather see floor control policy be defined as an independent = component (read: document).=20 Possibly, but I guess this does not relate to FC-reqs document. It has been agreed already that CPCP sets the floor policy.=20 > (Of course, e.g., XCAP could still be used to manipulate it, and it = should be=20 > linked with a conference policy). However, setting priviledges (who = can set up,=20 > change, remove floors) might still be good to have as a CPCP feature. Later, we may possibly define additional documents about different floor = policies but setting the policy is done via CPCP. > * REQ-6: Instead of a SHOULD, I think a MAY is more appropriate. What=20 > does a SHOULD mean in requirements anyway... I thought it means that solution should provide that but it is not = absolutely required Anyway, it can be changed to MAY. =20 > * REQ-13: Should this be a MUST? Of course, I would think the=20 > time you spend between requesting the floor and having the floor=20 > granted to you implicitly already means "queuing". It is not necessarily queueing (moderator is thinking about the = request:) The need to send status indication may depend on=20 the time it takes to complete the process, bandwidth/load issues etc. Therefore I guess SHOULD is ok. >=20 > * REQ-15: As above talks about floor policy descriptions, but=20 > maybe this term should be floor control policy, and described in the=20 > Model already. agreed, floor policy (or floor control policy) not both. > * REQ-17: I agree this requirement is important. SInce floors can be=20 > used across so many different types of conference=20 > applications - ranging from ones where floor operations are=20 > time sensitive to ones where they really aren't - we might=20 > really be talking about different protocols=20 > altogether. For elaborate descriptions in floor requests, you almost=20 > want something like email, whereas in simple mutex a much more simple=20 > protocol is required. Can the requirements somehow reflect=20 > this?=20 > I.e., make the smallest common denominator (the latter protocol)=20 > MUST, and everything on top a MAY? I'd rather have this kind of general requirement or remove it altogether (rather than detailed requirements for these 2 different scenarios). > * REQ-18: This again talks about a priviledge for a conference (e.g.,=20 > ABLE_TO_SEE_FLOOR). I don't believe current CPCP addresses this. Actually, this is not about CPCP privileges but about floor control and the floor holder list etc. There may be e.g. SIP floor event available to which users may subscribe. This is FC-requirement, maybe CPCP can later also support this privilege (otherwise, all users may subscribe to it). =20 > * REQ-19: Same as above, this seems like a conference priviledge that=20 > CPCP currently doesn't address. Also, what is the difference=20 > with REQ-18? This can probably be combined with REQ-18. -- Petri >=20 > * In Open Issues (Ch. 7): IMO, these privacy preferences aren't=20 > necessarily something that the floor requester should=20 > indicate; rather I think they should be set in the=20 > floor control policy, and indicated to=20 > all participants (i.e., I think it is the conference admin=20 > who decides what the privacy settings should be) > * Also, REQ-b sounds again like another priviledge in a conference=20 > (ABLE_TO_SEE_FLOOR_CHAIR). >=20 > --- >=20 > ext Adam Roach wrote: > > As a reminder, we are currently conducting a last call > > for the Floor Control Requirements document. This last > > call period ends in one week. Lacking any comments, the > > chairs will request publication as an RFC at that time. > >=20 > > /a > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Apr 22 10:41: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 KAA01201 for ; Thu, 22 Apr 2004 10:41: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 1BGf9X-0004vF-SL for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 10:26:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MEQBHD018915 for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 10:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGey1-0007dH-U5 for xcon-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 10:14: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 KAA28988 for ; Thu, 22 Apr 2004 10:14: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 1BGexu-0001or-3D for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 10:14:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGex2-0001ZE-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 10:13:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGewN-0001Is-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 10:12:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGemD-0008M5-33; Thu, 22 Apr 2004 10: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 1BGeZZ-0003a8-Mk for xcon@optimus.ietf.org; Thu, 22 Apr 2004 09:49:01 -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 JAA26853 for ; Thu, 22 Apr 2004 09:48:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeZR-0002zq-Lf for xcon@ietf.org; Thu, 22 Apr 2004 09:48:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeYU-0002kg-00 for xcon@ietf.org; Thu, 22 Apr 2004 09:47:55 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BGeXf-0002VM-00 for xcon@ietf.org; Thu, 22 Apr 2004 09:47:04 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MDl3m05800; Thu, 22 Apr 2004 16:47:03 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 16:46:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3MDkhlh023566; Thu, 22 Apr 2004 16:46:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00hVEwsO; Thu, 22 Apr 2004 16:46:41 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 i3MDkbs08901; Thu, 22 Apr 2004 16:46:37 +0300 (EET DST) Received: from nokia.com ([172.21.81.173]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 16:46:34 +0300 Message-ID: <4087CCBA.70808@nokia.com> Date: Thu, 22 Apr 2004 16:46:34 +0300 From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: "ext petri.koskelainen@nokia.com" CC: adam@dynamicsoft.com, xcon@ietf.org Subject: Re: [XCON] Reminder: FC Reqs last call References: <481D6FFB3BD60E4CB590F39C5909840001E9BD75@trebe004.europe.nokia.com> In-Reply-To: <481D6FFB3BD60E4CB590F39C5909840001E9BD75@trebe004.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 13:46:34.0536 (UTC) FILETIME=[39DBA280:01C42870] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline. ext petri.koskelainen@nokia.com wrote: >>* In the Model (4th Ch.), second para.: In the last sentence, I don't >>understand the benefit in singling out the case where the >>floor control server itself processes the floor control requests. >>Logically, there is still a floor chair, however now it is colocated with the server. > > > There isn't always a chair. Floor policy (set via CPCP) may define different policies > (say, fcfs) in which the server itself can take the decision. I agree there isn't always a "human" chair, but logically, whether co-located with the server or not, there is always a chair that has some policy in granting the floor (could be FCFS, a beauty-contest etc.). However, this isn't a big deal but more of a philosophical question. I don't think there's anything broken as such with the model. >>* REQ-13: Should this be a MUST? Of course, I would think the >>time you spend between requesting the floor and having the floor >>granted to you implicitly already means "queuing". > > > It is not necessarily queueing (moderator is thinking about the request:) > The need to send status indication may depend on > the time it takes to complete the process, bandwidth/load issues etc. > Therefore I guess SHOULD is ok. I'm sorry, I meant to say "pending". I agree some sort of status indication is needed. In fact, it seems that the requestor needs to get an immediate response (either showing pending state, or granted/denied), and in case of pending, needs the final response within a finite time period (time-outs). This is why I actually think this is a MUST requirement. >>* REQ-17: I agree this requirement is important. SInce floors can be >>used across so many different types of conference >>applications - ranging from ones where floor operations are >>time sensitive to ones where they really aren't - we might >>really be talking about different protocols >>altogether. For elaborate descriptions in floor requests, you almost >>want something like email, whereas in simple mutex a much more simple >>protocol is required. Can the requirements somehow reflect >>this? >>I.e., make the smallest common denominator (the latter protocol) >>MUST, and everything on top a MAY? > > > I'd rather have this kind of general requirement or remove it altogether > (rather than detailed requirements for these 2 different scenarios). Yeah, I guess I'm happy with just having a general requirement like this. >>* REQ-18: This again talks about a priviledge for a conference (e.g., >>ABLE_TO_SEE_FLOOR). I don't believe current CPCP addresses this. > > > Actually, this is not about CPCP privileges but about floor control > and the floor holder list etc. There may be e.g. SIP floor event > available to which users may subscribe. This is FC-requirement, > maybe CPCP can later also support this privilege (otherwise, > all users may subscribe to it). I'm a bit confused. To me they look like priviledges that are given to conference participants, and as such I don't see a difference in granting ability to subscribe to conference-info and granting ability to subscribe to floor events. Granted, these may actually pend on whether the participant was allowed into the conference in the first place. Am I missing something? >>* REQ-19: Same as above, this seems like a conference priviledge that >>CPCP currently doesn't address. Also, what is the difference >>with REQ-18? > > > This can probably be combined with REQ-18. Agreed. >>* In Open Issues (Ch. 7): IMO, these privacy preferences aren't >>necessarily something that the floor requester should >>indicate; rather I think they should be set in the >>floor control policy, and indicated to >>all participants (i.e., I think it is the conference admin >>who decides what the privacy settings should be) >>* Also, REQ-b sounds again like another priviledge in a conference >>(ABLE_TO_SEE_FLOOR_CHAIR). BTW, you missed the last two comments. ;) Although the second one is pretty much the same issue as above with REQ-18/19. Cheers, AKi _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Apr 23 00:03:08 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 AAA25561 for ; Fri, 23 Apr 2004 00:03: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 1BGroE-0005UK-RH for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 23:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N3v2aH021092 for xcon-archive@odin.ietf.org; Thu, 22 Apr 2004 23:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrh7-00030l-BR for xcon-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 23:49: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 XAA25065 for ; Thu, 22 Apr 2004 23:49: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 1BGrh3-0005cg-5C for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 23:49:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGrfw-0005LA-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 23:48:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGret-0004vi-00 for xcon-web-archive@ietf.org; Thu, 22 Apr 2004 23:47:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrZh-0001Gw-38; Thu, 22 Apr 2004 23:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrRX-0006aU-95 for xcon@optimus.ietf.org; Thu, 22 Apr 2004 23:33:35 -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 XAA24469 for ; Thu, 22 Apr 2004 23:33:31 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGrRT-0001Jn-5j for xcon@ietf.org; Thu, 22 Apr 2004 23:33:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGrQZ-00013y-00 for xcon@ietf.org; Thu, 22 Apr 2004 23:32:36 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BGrPn-0000X9-00 for xcon@ietf.org; Thu, 22 Apr 2004 23:31:48 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i3N3V6In029847 for ; Fri, 23 Apr 2004 09:01:06 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 23 Apr 2004 09:01:05 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Apr 2004 09:01:05 +0530 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Reminder: FC Reqs last call Date: Fri, 23 Apr 2004 09:01:03 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E2130301A6@blr-ec-msg04.wipro.com> Thread-Topic: [XCON] Reminder: FC Reqs last call Thread-Index: AcQoV6+Xh4kY7+WDR8WlkkDmuPBB+QAiNs2g To: , Cc: X-OriginalArrivalTime: 23 Apr 2004 03:31:05.0204 (UTC) FILETIME=[68AC8340:01C428E3] 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 My comments: IN REQ-18: Conference members and the chair MUST have the capability to learn who has the floor and who has requested the floor. (Note: Conference policy may prevent members seeing this.) In open issues we have: In RRQ-a we have "It MUST be possible for the floor requester to indicate her privacy preference"options :anonymous and we have RRQ-b to hide. So,as per requirements we are confirming that, Conference members and the chair MUST have the capability=20 To learn who has floor and who has requested the floor. But we still have a open issue on this!!! So why dont we make as SHOULD. >>* REQ-6: Instead of a SHOULD, I think a MAY is more appropriate. What=20 >>does a SHOULD mean in requirements anyway... I think SHOULD is correctr because "we expect to" be possible for a user.....=20 >>* REQ-13: Should this be a MUST? Of course, I would think the time you >>spend between requesting the floor and having the floor granted to you >>implicitly already means "queuing". This should be SHOULD only because you cannot restrict by telling that you MUST Inform that the floor request is pending...It is "expected to" to that(it is upto the implementation again to make it or not). In SIP,we have 183,180 which are optional. Similary here also. Regards, SReeram -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Niemi Aki (Nokia-M/Espoo) Sent: Thursday, April 22, 2004 4:08 PM To: ext Adam Roach Cc: 'xcon@ietf.org' Subject: Re: [XCON] Reminder: FC Reqs last call Hi, Apologies for late comments. Especially since the chairs did a great job in reminding us about the approaching DL. Shame on me... ;) Cheers, Aki --- * In the Introduction (1st Ch.), 5th para: I wonder if there is=20 something specific in these studies that is to be leveraged? If so,=20 maybe it should be mentioned here. * In the Model (4th Ch.), second para.: In the last sentence, I don't=20 understand the benefit in singling out the case where the floor control=20 server itself processes the floor control requests. Logically, there is=20 still a floor chair, however now it is colocated with the server. * 4th Ch., 4th para: this talks about policy data pertaining to a floor, that is outside the actual floor control protocol. Perhaps we need to=20 explicitly talk about floor control policy here. (It's briefly mentioned in REQ 15, nowhere else.) * In the Integration (Ch. 5), first para: this suggests CPCP take care=20 of setting floor control policy. I'd rather see floor control policy be=20 defined as an independent component (read: document). (Of course, e.g.,=20 XCAP could still be used to manipulate it, and it should be linked with=20 a conference policy). However, setting priviledges (who can set up,=20 change, remove floors) might still be good to have as a CPCP feature. * REQ-6: Instead of a SHOULD, I think a MAY is more appropriate. What=20 does a SHOULD mean in requirements anyway... * REQ-13: Should this be a MUST? Of course, I would think the time you=20 spend between requesting the floor and having the floor granted to you=20 implicitly already means "queuing". * REQ-15: As above talks about floor policy descriptions, but maybe this term should be floor control policy, and described in the Model already. * REQ-17: I agree this requirement is important. SInce floors can be=20 used across so many different types of conference applications - ranging from ones where floor operations are time sensitive to ones where they=20 really aren't - we might really be talking about different protocols=20 altogether. For elaborate descriptions in floor requests, you almost=20 want something like email, whereas in simple mutex a much more simple=20 protocol is required. Can the requirements somehow reflect this? I.e.,=20 make the smallest common denominator (the latter protocol) MUST, and=20 everything on top a MAY? * REQ-18: This again talks about a priviledge for a conference (e.g.,=20 ABLE_TO_SEE_FLOOR). I don't believe current CPCP addresses this. * REQ-19: Same as above, this seems like a conference priviledge that=20 CPCP currently doesn't address. Also, what is the difference with REQ-18? * In Open Issues (Ch. 7): IMO, these privacy preferences aren't=20 necessarily something that the floor requester should indicate; rahter I think they should be set in the floor control policy, and indicated to=20 all participants (i.e., I think it is the conference admin who decides=20 what the privacy settings should be) * Also, REQ-b sounds again like another priviledge in a conference=20 (ABLE_TO_SEE_FLOOR_CHAIR). --- ext Adam Roach wrote: > As a reminder, we are currently conducting a last call > for the Floor Control Requirements document. This last > call period ends in one week. Lacking any comments, the chairs will=20 > request publication as an RFC at that time. >=20 > /a >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Apr 26 16:58:20 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 QAA20743 for ; Mon, 26 Apr 2004 16:58:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICyd-00068w-VX for xcon-archive@odin.ietf.org; Mon, 26 Apr 2004 16:45:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QKjJMq023610 for xcon-archive@odin.ietf.org; Mon, 26 Apr 2004 16:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIC9P-0004mt-SF for xcon-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 15:52: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 PAA15476 for ; Mon, 26 Apr 2004 15:52: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 1BIC9O-0002zo-DT for xcon-web-archive@ietf.org; Mon, 26 Apr 2004 15:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIC8e-0002vk-00 for xcon-web-archive@ietf.org; Mon, 26 Apr 2004 15:51:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIC81-0002qw-00 for xcon-web-archive@ietf.org; Mon, 26 Apr 2004 15:50:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBpp-0000ZV-5b; Mon, 26 Apr 2004 15:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBjh-0008B3-VQ for xcon@optimus.ietf.org; Mon, 26 Apr 2004 15:25:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13121; Mon, 26 Apr 2004 15:25:47 -0400 (EDT) Message-Id: <200404261925.PAA13121@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, 26 Apr 2004 15:25:47 -0400 Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-03.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 : Requirements for Conference Policy Control Protocol Author(s) : P. Koskelainen, H. Khartabil Filename : draft-ietf-xcon-cpcp-reqs-03.txt Pages : 21 Date : 2004-4-26 The conference policy server allows clients to manipulate and interact with the conference policy. One mechanism to manipulate the policy is to use conference policy control protocol (CPCP). This document gives the requirements for CPCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-03.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-reqs-03.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-reqs-03.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-4-26150327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-cpcp-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150327.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Apr 26 17:58:42 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 RAA26824 for ; Mon, 26 Apr 2004 17:58: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 1BIDus-0006Kn-T8 for xcon-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLjUeK024336 for xcon-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDjE-0003JI-2H for xcon-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:33:28 -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 RAA25379 for ; Mon, 26 Apr 2004 17:33:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDjB-0006R4-Lo for xcon-web-archive@ietf.org; Mon, 26 Apr 2004 17:33:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDiF-0006N2-00 for xcon-web-archive@ietf.org; Mon, 26 Apr 2004 17:32:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDhn-0006J6-00 for xcon-web-archive@ietf.org; Mon, 26 Apr 2004 17:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYi-0000oT-AI; Mon, 26 Apr 2004 17:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDHw-0003w4-RH for xcon@optimus.ietf.org; Mon, 26 Apr 2004 17:05:16 -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 RAA22277 for ; Mon, 26 Apr 2004 17:05: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 1BIDHu-0003N5-M0 for xcon@ietf.org; Mon, 26 Apr 2004 17:05:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDCO-0002Od-00 for xcon@ietf.org; Mon, 26 Apr 2004 16:59:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BID4Q-0000rv-00 for xcon@ietf.org; Mon, 26 Apr 2004 16:51:20 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QKoeW9018785 for ; Mon, 26 Apr 2004 13:50:41 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHW65150; Mon, 26 Apr 2004 16:50:39 -0400 (EDT) Message-ID: <408D761F.1080001@cisco.com> Date: Mon, 26 Apr 2004 16:50:39 -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: xcon@ietf.org References: <200404261925.PAA13121@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Re:draft-ietf-xcon-cpcp-reqs-03.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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One small point: 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. I think "time when" probably ought to be "time after which". Otherwise, it becomes ambiguous what happens if users are added to the dialout list after that time has passed. (Presumably users added after that time should be invited immediately.) Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Apr 28 09:29:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14890 for ; Wed, 28 Apr 2004 09:29:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoyJ-0003Z0-0T for xcon-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SDJUuN013698 for xcon-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIomF-0000Cy-K5 for xcon-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 09:07:04 -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 JAA13414 for ; Wed, 28 Apr 2004 09:07: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 1BIomD-0002hw-Jw for xcon-web-archive@ietf.org; Wed, 28 Apr 2004 09:07:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIolK-0002ch-00 for xcon-web-archive@ietf.org; Wed, 28 Apr 2004 09:06:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIokn-0002YC-00 for xcon-web-archive@ietf.org; Wed, 28 Apr 2004 09:05:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoaC-0006cT-Hg; Wed, 28 Apr 2004 08:54:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIngN-0003UW-7O for xcon@optimus.ietf.org; Wed, 28 Apr 2004 07: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 HAA08856 for ; Wed, 28 Apr 2004 07:56:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIngM-0001YP-Ba for xcon@ietf.org; Wed, 28 Apr 2004 07:56:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInfM-0001Ch-00 for xcon@ietf.org; Wed, 28 Apr 2004 07:55:53 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIneM-0000r1-00 for xcon@ietf.org; Wed, 28 Apr 2004 07:54:50 -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 i3SBsFG10742; Wed, 28 Apr 2004 14:54:16 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 14:53:54 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3SBrsEt001825; Wed, 28 Apr 2004 14:53:54 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00qiV9D9; Wed, 28 Apr 2004 14:46:13 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 i3SBkCH17168; Wed, 28 Apr 2004 14:46:12 +0300 (EET DST) Received: from nokia.com ([10.162.252.147]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 14:46:12 +0300 Message-ID: <408F997D.9050404@nokia.com> Date: Wed, 28 Apr 2004 14:46:05 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 0.6+ (X11/20040421) X-Accept-Language: en MIME-Version: 1.0 To: 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)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2004 11:46:12.0402 (UTC) FILETIME=[679BF120:01C42D16] Content-Transfer-Encoding: 7bit Subject: [XCON] Authorization in conference 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, 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 From exim@www1.ietf.org Fri Apr 30 17:19:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04001 for ; Fri, 30 Apr 2004 17:19: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 1BJf88-0004rk-0p for xcon-archive@odin.ietf.org; Fri, 30 Apr 2004 17:01:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UL170Q018688 for xcon-archive@odin.ietf.org; Fri, 30 Apr 2004 17:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeRj-0006bx-23 for xcon-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 16:17: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 QAA27938 for ; Fri, 30 Apr 2004 16:17: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 1BJeRh-0001MY-BP for xcon-web-archive@ietf.org; Fri, 30 Apr 2004 16:17:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeQq-0001IL-00 for xcon-web-archive@ietf.org; Fri, 30 Apr 2004 16:16:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJeQ3-0001E2-00 for xcon-web-archive@ietf.org; Fri, 30 Apr 2004 16:15:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe7A-0003Lx-V2; Fri, 30 Apr 2004 15:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdw0-00075X-Dj for xcon@optimus.ietf.org; Fri, 30 Apr 2004 15:44:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26158; Fri, 30 Apr 2004 15:44:27 -0400 (EDT) Message-Id: <200404301944.PAA26158@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: Fri, 30 Apr 2004 15:44:27 -0400 Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-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-00.txt Pages : 32 Date : 2004-4-30 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-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-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-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-4-30160308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-cpcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-cpcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-30160308.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon