From exim@www1.ietf.org Tue Jan 6 07:29:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16317 for ; Tue, 6 Jan 2004 07:29: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 1AdqKo-0007oj-Sg for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 07:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06CTM2R030048 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 07:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqKo-0007oZ-LP for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 07:29:22 -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 HAA16205 for ; Tue, 6 Jan 2004 07:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdqKo-0002Cn-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdqHs-0001zm-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:26:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdqD4-0001nl-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:21:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqCi-0007ee-Jc; Tue, 06 Jan 2004 07:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqBt-0007cG-3Q for xcon@optimus.ietf.org; Tue, 06 Jan 2004 07:20:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16066 for ; Tue, 6 Jan 2004 07:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdqBi-0001kQ-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:19:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adq8n-0001dM-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:16:58 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1Adq5d-0001UE-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:13:42 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 14:12:42 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Media policy Date: Tue, 6 Jan 2004 14:12:41 +0200 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=none autolearn=no version=2.60 Hisham, During the ad-hoc group discussion it looked to us that media policy is tied to a conference. Mostly the example you had about which media are allowed in the conference and even at what rates. Since conference policy and media policy may be used by an application server to create conferences based on the user service agreement then the application server may need to be able to tell the conference bridge those parameters. Regards Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Monday, December 15, 2003 2:58 PM To: xcon@ietf.org Subject: [XCON] CPCP Requirement: Media policy This is in reference to requirement REQ-D1 in http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt REQ-D1: It MAY be possible to define media policy within conference policy. We all know that conference policy, as defined today, encapsulates media policy. Should CPCP carry that media policy? At least for things like media types (Audio, video, text, etc)? Regards, Hisham _______________________________________________ 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 Jan 6 07:30:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16377 for ; Tue, 6 Jan 2004 07:30:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqLB-0007q2-E9 for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 07:29:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06CTjxp030124 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 07:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqLB-0007pj-5k for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 07:29:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16270 for ; Tue, 6 Jan 2004 07:29:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdqLA-0002Hx-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:29:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdqIz-00024k-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:27:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdqFm-0001tq-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:24:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqFc-0007iC-R4; Tue, 06 Jan 2004 07:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqEy-0007hO-BU for xcon@optimus.ietf.org; Tue, 06 Jan 2004 07:23: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 HAA16094 for ; Tue, 6 Jan 2004 07:23:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdqEs-0001rP-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:23:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adq9y-0001ha-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:18:11 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1Adq8i-0001bP-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:16:52 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 14:16:10 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 6 Jan 2004 14:16:08 +0200 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=none autolearn=no version=2.60 Hi, My opinion is that the conference policy needs only a conference duration parameter if any. I think that reservation is an external application to the focus. According to the conference framework the focus is using the information in the conference policy server and the focus is not the right place for reservation. Regards Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Monday, December 15, 2003 4:57 PM To: xcon@ietf.org Subject: [XCON] CPCP Requirement: Repeat times A conference has start and stop times. Although the current proposed solution has repeat times (eg: meeting repeats weekly), there is no requirement for such. Do we see a need for such capability using CPCP? If so, then we need to add a requirement. Regards, Hisham _______________________________________________ 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 Jan 6 07:34:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16555 for ; Tue, 6 Jan 2004 07:34:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqP6-0007wQ-Di for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 07:33:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06CXms6030520 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 07:33:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqP6-0007wB-72 for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 07:33:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16536 for ; Tue, 6 Jan 2004 07:33:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdqP5-0002Zm-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:33:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdqNF-0002Tb-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:31:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdqLS-0002LS-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 07:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqLS-0007rF-Gv; Tue, 06 Jan 2004 07:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdqL3-0007pa-0m for xcon@optimus.ietf.org; Tue, 06 Jan 2004 07:29:38 -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 HAA16241 for ; Tue, 6 Jan 2004 07:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdqL2-0002G2-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdqI8-00022N-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:26:36 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AdqEW-0001qL-00 for xcon@ietf.org; Tue, 06 Jan 2004 07:22:52 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 14:22:10 +0200 Message-ID: From: "Even, Roni" To: "'Rosen, Brian'" , "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 6 Jan 2004 14:22:09 +0200 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=none autolearn=no version=2.60 Brian, My suggestion is not to have reservation in the conference policy. The conference policy is used by the focus according to the conference framework and the focus is not the place for handling reservation. I think that reservation is handled by an external application server that will start the conference using CPCP at the time when the conference scheduled time has arrived. The focus may use the conference duration information in order to notify the participants that it the conference end-time is coming and terminate the conference. Extension of the should be done using CPCP either by the participant or an application server. 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Monday, December 15, 2003 4:25 PM To: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Again, I'm worried about "privileged users". I think we need to finish some discussions we started a while ago that essentially are semantics. What is an "inactivated" conference, and how does it differ from a conference that can be re-instantiated (a weekly meeting for example)? Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: de-activating a conference > > > This is in reference to requirement REQ-B9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B9: It MUST be possible to inactive a conference for defined > period of time. > > There are start and stop times for a conference. A conference > might live for days, weeks or even months. Should a > conference policy, using CPCP, allow a privileged user to > de-activate a conference for a period of time within the > start and stop times of a conference? Examples are > administrator is performing some maintenance. > > Regards, > Hisham > > _______________________________________________ > 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 Jan 6 09:30:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19204 for ; Tue, 6 Jan 2004 09:30:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsDz-00038D-VO for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 09:30:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06EURts012031 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 09:30:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsDy-00037x-Cz for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 09:30:26 -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 JAA19198 for ; Tue, 6 Jan 2004 09:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsDw-00075r-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsC8-0006yM-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:28:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ads9Y-0006la-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:25:52 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ads9B-000296-6n for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:25:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ads8j-0002gq-1v; Tue, 06 Jan 2004 09:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ads8E-0002fz-6Z for xcon@optimus.ietf.org; Tue, 06 Jan 2004 09:24:40 -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 JAA18932 for ; Tue, 6 Jan 2004 09:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ads81-0006im-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ads3F-0006Xc-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:19:22 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1Adrz5-0006Nz-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:15:03 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24681; Tue, 6 Jan 2004 09:14:02 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14875; Tue, 6 Jan 2004 09:14:01 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 09:14:01 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6253@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Even, Roni'" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 6 Jan 2004 09:13:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I don't like this idea because I think that we need a standardized interface for scheduling and "external application server" sounds very proprietary to me. I guess I could be convinced we need a separate interface, with a separate protocol (maybe it could be iCal), but I'm not yet convinced just specifying a start time in the future isn't a sufficient reservation mechanism. Brian -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, January 06, 2004 7:22 AM To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Brian, My suggestion is not to have reservation in the conference policy. The conference policy is used by the focus according to the conference framework and the focus is not the place for handling reservation. I think that reservation is handled by an external application server that will start the conference using CPCP at the time when the conference scheduled time has arrived. The focus may use the conference duration information in order to notify the participants that it the conference end-time is coming and terminate the conference. Extension of the should be done using CPCP either by the participant or an application server. 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Monday, December 15, 2003 4:25 PM To: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Again, I'm worried about "privileged users". I think we need to finish some discussions we started a while ago that essentially are semantics. What is an "inactivated" conference, and how does it differ from a conference that can be re-instantiated (a weekly meeting for example)? Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: de-activating a conference > > > This is in reference to requirement REQ-B9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B9: It MUST be possible to inactive a conference for defined > period of time. > > There are start and stop times for a conference. A conference > might live for days, weeks or even months. Should a > conference policy, using CPCP, allow a privileged user to > de-activate a conference for a period of time within the > start and stop times of a conference? Examples are > administrator is performing some maintenance. > > Regards, > Hisham > > _______________________________________________ > 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 Jan 6 09:34:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19442 for ; Tue, 6 Jan 2004 09:34:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsHJ-0003M2-MV for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 09:33:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06EXre3012888 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 09:33:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsHJ-0003Ln-Hr for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 09:33:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19394 for ; Tue, 6 Jan 2004 09:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsHH-0007K5-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:33:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsFd-0007Ey-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:32:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AdsEn-00077u-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:31:17 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AdsEc-0002d5-Ml for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsEZ-0003Ae-5i; Tue, 06 Jan 2004 09:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsDZ-00036d-NY for xcon@optimus.ietf.org; Tue, 06 Jan 2004 09:30:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19144 for ; Tue, 6 Jan 2004 09:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsDY-00072a-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsBd-0006si-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:28:02 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1Ads7P-0006fn-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:23:39 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 16:22:33 +0200 Message-ID: From: "Even, Roni" To: "'Rosen, Brian'" , "Even, Roni" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 6 Jan 2004 16:22:32 +0200 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=none autolearn=no version=2.60 Brian, So you see the focus as managing reservation, this means we have to go back to the framework document and decide how to handle reservation. I did not see the requirement to have it as part of the conferencing architecture since it does not apply only to conferencing. Reservation is a general topic that address also the conference rooms, the people and the equipment. That is why I think it is outside of the conferencing architecture Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, January 06, 2004 4:14 PM To: 'Even, Roni' Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference I don't like this idea because I think that we need a standardized interface for scheduling and "external application server" sounds very proprietary to me. I guess I could be convinced we need a separate interface, with a separate protocol (maybe it could be iCal), but I'm not yet convinced just specifying a start time in the future isn't a sufficient reservation mechanism. Brian -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, January 06, 2004 7:22 AM To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Brian, My suggestion is not to have reservation in the conference policy. The conference policy is used by the focus according to the conference framework and the focus is not the place for handling reservation. I think that reservation is handled by an external application server that will start the conference using CPCP at the time when the conference scheduled time has arrived. The focus may use the conference duration information in order to notify the participants that it the conference end-time is coming and terminate the conference. Extension of the should be done using CPCP either by the participant or an application server. 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Monday, December 15, 2003 4:25 PM To: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Again, I'm worried about "privileged users". I think we need to finish some discussions we started a while ago that essentially are semantics. What is an "inactivated" conference, and how does it differ from a conference that can be re-instantiated (a weekly meeting for example)? Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: de-activating a conference > > > This is in reference to requirement REQ-B9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B9: It MUST be possible to inactive a conference for defined > period of time. > > There are start and stop times for a conference. A conference > might live for days, weeks or even months. Should a > conference policy, using CPCP, allow a privileged user to > de-activate a conference for a period of time within the > start and stop times of a conference? Examples are > administrator is performing some maintenance. > > Regards, > Hisham > > _______________________________________________ > 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 Jan 6 09:54:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19989 for ; Tue, 6 Jan 2004 09:54:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsaR-0004Ab-Po for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 09:53:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06ErdR1016023 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 09:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsaR-0004AM-Kf for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 09:53:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19976 for ; Tue, 6 Jan 2004 09:53:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsaP-0000Hl-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:53:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsYd-0000EW-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:51:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdsWu-0000AZ-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 09:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsWv-00040T-1x; Tue, 06 Jan 2004 09:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsWm-00040A-8S for xcon@optimus.ietf.org; Tue, 06 Jan 2004 09:49:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19872 for ; Tue, 6 Jan 2004 09:49:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsWi-00008Y-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsUp-00004h-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:47:52 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AdsUO-00000j-00 for xcon@ietf.org; Tue, 06 Jan 2004 09:47:24 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25884; Tue, 6 Jan 2004 09:46:50 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19083; Tue, 6 Jan 2004 09:46:49 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 09:46:49 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6256@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Even, Roni'" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 6 Jan 2004 09:46:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Clearly, xcon can only address the "equipment" part of the problem. What is wrong with making the start time in the future? I think it is quite sufficient. The actual mechanism the focus uses to maintain resource reservation is beyond scope, but the actual reservation seems to be simple. Brian -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, January 06, 2004 9:23 AM To: 'Rosen, Brian'; Even, Roni Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Brian, So you see the focus as managing reservation, this means we have to go back to the framework document and decide how to handle reservation. I did not see the requirement to have it as part of the conferencing architecture since it does not apply only to conferencing. Reservation is a general topic that address also the conference rooms, the people and the equipment. That is why I think it is outside of the conferencing architecture Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, January 06, 2004 4:14 PM To: 'Even, Roni' Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference I don't like this idea because I think that we need a standardized interface for scheduling and "external application server" sounds very proprietary to me. I guess I could be convinced we need a separate interface, with a separate protocol (maybe it could be iCal), but I'm not yet convinced just specifying a start time in the future isn't a sufficient reservation mechanism. Brian -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Tuesday, January 06, 2004 7:22 AM To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Brian, My suggestion is not to have reservation in the conference policy. The conference policy is used by the focus according to the conference framework and the focus is not the place for handling reservation. I think that reservation is handled by an external application server that will start the conference using CPCP at the time when the conference scheduled time has arrived. The focus may use the conference duration information in order to notify the participants that it the conference end-time is coming and terminate the conference. Extension of the should be done using CPCP either by the participant or an application server. 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Monday, December 15, 2003 4:25 PM To: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Again, I'm worried about "privileged users". I think we need to finish some discussions we started a while ago that essentially are semantics. What is an "inactivated" conference, and how does it differ from a conference that can be re-instantiated (a weekly meeting for example)? Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 7:57 AM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: de-activating a conference > > > This is in reference to requirement REQ-B9 in > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > REQ-B9: It MUST be possible to inactive a conference for defined > period of time. > > There are start and stop times for a conference. A conference > might live for days, weeks or even months. Should a > conference policy, using CPCP, allow a privileged user to > de-activate a conference for a period of time within the > start and stop times of a conference? Examples are > administrator is performing some maintenance. > > Regards, > Hisham > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 6 11:58:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25055 for ; Tue, 6 Jan 2004 11:58:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduWV-0000Ef-CJ for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 11:57:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Gvhlx000900 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 11:57:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduWV-0000ER-6N for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 11:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25011 for ; Tue, 6 Jan 2004 11:57:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AduWT-00054P-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 11:57:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AduUe-0004zk-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 11:55:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AduSv-0004vJ-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 11:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduSu-000092-Uy; Tue, 06 Jan 2004 11:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduSk-00008C-LR for xcon@optimus.ietf.org; Tue, 06 Jan 2004 11:53:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24892 for ; Tue, 6 Jan 2004 11:53:47 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AduSj-0004tO-00 for xcon@ietf.org; Tue, 06 Jan 2004 11:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AduQx-0004om-00 for xcon@ietf.org; Tue, 06 Jan 2004 11:52:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AduPi-0004jK-00 for xcon@ietf.org; Tue, 06 Jan 2004 11:50:42 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i06Goe620561 for ; Tue, 6 Jan 2004 18:50:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 6 Jan 2004 18:50:39 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 6 Jan 2004 18:50:39 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 6 Jan 2004 18:50:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 6 Jan 2004 18:50:37 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0C29@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPUT/61Sk1wawARQ++o7/Es23uRcQAIuf3Q To: , , X-OriginalArrivalTime: 06 Jan 2004 16:50:37.0422 (UTC) FILETIME=[35BB10E0:01C3D475] 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 Roni, > My opinion is that the conference policy needs only a=20 > conference duration parameter if any.=20 > I think that reservation is an external=20 > application to the focus. According to the conference=20 > framework the focus is using the information in the=20 > conference policy server and the focus is=20 > not the right place for reservation. The reservation is sent to CPS, not to focus. I think it makes sense to have this (repeat time) capability in protocol since we need the feature anyway in real-world (either in CPCP or in some new mystery protocol between the user and the reservation = application). -- Petri > Regards > Roni Even >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 4:57 PM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Repeat times >=20 >=20 > A conference has start and stop times. Although the current proposed > solution has repeat times (eg: meeting repeats weekly), there is no > requirement for such. >=20 > Do we see a need for such capability using CPCP? If so, then=20 > we need to add > a requirement. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 6 12:26:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25784 for ; Tue, 6 Jan 2004 12:26:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aduy9-0001IX-79 for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 12:26:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06HQHb9004986 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 12:26:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aduy9-0001IL-0d for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 12:26:17 -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 MAA25761 for ; Tue, 6 Jan 2004 12:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aduy0-0006Fc-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 12:26:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adut4-00061C-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 12:21:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdupU-0005p5-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 12:17:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdupB-00018B-HC; Tue, 06 Jan 2004 12:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aduoq-00017P-6T for xcon@optimus.ietf.org; Tue, 06 Jan 2004 12:16:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25468 for ; Tue, 6 Jan 2004 12:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aduoj-0005nC-00 for xcon@ietf.org; Tue, 06 Jan 2004 12:16:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdujA-0005Zt-00 for xcon@ietf.org; Tue, 06 Jan 2004 12:10:49 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1Adufg-0005Mh-00 for xcon@ietf.org; Tue, 06 Jan 2004 12:07:12 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 19:06:13 +0200 Message-ID: From: "Even, Roni" To: "'petri.koskelainen@nokia.com '" , "Even, Roni" , "'hisham.khartabil@nokia.com '" , "'xcon@ietf.org '" Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 6 Jan 2004 19:06:11 +0200 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=none autolearn=no version=2.60 Hi Petri, The CPS is a data storage that is used by the focus, so the focus will have to handle the reservation Roni -----Original Message----- From: petri.koskelainen@nokia.com To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; xcon@ietf.org Sent: 06/01/2004 18:50 Subject: RE: [XCON] CPCP Requirement: Repeat times Hi Roni, > My opinion is that the conference policy needs only a > conference duration parameter if any. > I think that reservation is an external > application to the focus. According to the conference > framework the focus is using the information in the > conference policy server and the focus is > not the right place for reservation. The reservation is sent to CPS, not to focus. I think it makes sense to have this (repeat time) capability in protocol since we need the feature anyway in real-world (either in CPCP or in some new mystery protocol between the user and the reservation application). -- Petri > Regards > Roni Even > > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, December 15, 2003 4:57 PM > To: xcon@ietf.org > Subject: [XCON] CPCP Requirement: Repeat times > > > A conference has start and stop times. Although the current proposed > solution has repeat times (eg: meeting repeats weekly), there is no > requirement for such. > > Do we see a need for such capability using CPCP? If so, then > we need to add > a requirement. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 6 12:45:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25057 for ; Tue, 6 Jan 2004 11:58:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduWV-0000Ey-RZ for xcon-archive@odin.ietf.org; Tue, 06 Jan 2004 11:57:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Gvhv7000917 for xcon-archive@odin.ietf.org; Tue, 6 Jan 2004 11:57:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduWV-0000Ei-Ma for xcon-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 11:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25014 for ; Tue, 6 Jan 2004 11:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AduWU-00054U-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 11:57:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AduUf-0004zt-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 11:55:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AduSv-0004vK-00 for xcon-web-archive@ietf.org; Tue, 06 Jan 2004 11:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduSv-00009D-8u; Tue, 06 Jan 2004 11:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduSl-00008G-5o for xcon@optimus.ietf.org; Tue, 06 Jan 2004 11:53:51 -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 LAA24895 for ; Tue, 6 Jan 2004 11:53:47 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AduSj-0004tV-00 for xcon@ietf.org; Tue, 06 Jan 2004 11:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AduQy-0004ou-00 for xcon@ietf.org; Tue, 06 Jan 2004 11:52:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AduPl-0004jM-00 for xcon@ietf.org; Tue, 06 Jan 2004 11:50:45 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i06Goi620643 for ; Tue, 6 Jan 2004 18:50:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 6 Jan 2004 18:50:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 6 Jan 2004 18:50:45 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 6 Jan 2004 18:50:44 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 6 Jan 2004 18:50:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 6 Jan 2004 18:50:43 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0C2A@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: de-activating a conference Thread-Index: AcPUZGP41xqZAvm3RWedM16SYrIwpgAEK1NA To: , Cc: , X-OriginalArrivalTime: 06 Jan 2004 16:50:45.0038 (UTC) FILETIME=[3A452CE0:01C3D475] 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 I agree with Brian. Petri > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Rosen, Brian > Sent: 06 January, 2004 16:47 > To: 'Even, Roni' > Cc: Khartabil Hisham (Nokia-TP/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Clearly, xcon can only address the "equipment" part of the problem. >=20 > What is wrong with making the start time in the future? I think it is > quite sufficient. The actual mechanism the focus uses to maintain > resource reservation is beyond scope, but the actual reservation seems > to be simple. >=20 > Brian >=20 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, January 06, 2004 9:23 AM > To: 'Rosen, Brian'; Even, Roni > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Brian, > So you see the focus as managing reservation, this means we=20 > have to go back > to the framework document and decide how to handle=20 > reservation. I did not > see the requirement to have it as part of the conferencing=20 > architecture > since it does not apply only to conferencing. Reservation is=20 > a general topic > that address also the conference rooms, the people and the=20 > equipment. That > is why I think it is outside of the conferencing architecture > Roni Even >=20 > ************************************* > Roni Even >=20 > Polycom Israel >=20 > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, January 06, 2004 4:14 PM > To: 'Even, Roni' > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > I don't like this idea because I think that we need a=20 > standardized interface > for scheduling and "external application server" sounds very=20 > proprietary to > me. I guess I could be convinced we need a separate interface, with a > separate protocol (maybe it could be iCal), but I'm not yet convinced > just specifying a start time in the future isn't a sufficient=20 > reservation > mechanism. >=20 > Brian >=20 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, January 06, 2004 7:22 AM > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Brian, > My suggestion is not to have reservation in the conference policy. The > conference policy is used by the focus according to the=20 > conference framework > and the focus is not the place for handling reservation. I think that > reservation is handled by an external application server that=20 > will start the > conference using CPCP at the time when the conference=20 > scheduled time has > arrived. The focus may use the conference duration=20 > information in order to > notify the participants that it the conference end-time is coming and > terminate the conference. Extension of the should be done=20 > using CPCP either > by the participant or an application server. > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, December 15, 2003 4:25 PM > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Again, I'm worried about "privileged users". I think we need=20 > to finish > some discussions we started a while ago that essentially are=20 > semantics. > What is an "inactivated" conference, and how does it differ from a > conference that can be re-instantiated (a weekly meeting for example)? >=20 > Brian >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: de-activating a conference > >=20 > >=20 > > This is in reference to requirement REQ-B9 in=20 > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >=20 > > REQ-B9: It MUST be possible to inactive a conference for defined > > period of time. > >=20 > > There are start and stop times for a conference. A conference=20 > > might live for days, weeks or even months. Should a=20 > > conference policy, using CPCP, allow a privileged user to=20 > > de-activate a conference for a period of time within the=20 > > start and stop times of a conference? Examples are=20 > > administrator is performing some maintenance. > >=20 > > Regards, > > Hisham > > >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 7 04:30:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29152 for ; Wed, 7 Jan 2004 04:30:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeA0j-0008Jn-Ab for xcon-archive@odin.ietf.org; Wed, 07 Jan 2004 04:29:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i079Tvtq031973 for xcon-archive@odin.ietf.org; Wed, 7 Jan 2004 04:29:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeA0i-0008Jb-H3 for xcon-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 04:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29118 for ; Wed, 7 Jan 2004 04:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeA0f-0004LI-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 04:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae9yj-0004GI-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 04:27:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae9wv-0004Ci-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 04:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae9wv-0008B4-MU; Wed, 07 Jan 2004 04:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae9wp-0008AH-A2 for xcon@optimus.ietf.org; Wed, 07 Jan 2004 04:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29017 for ; Wed, 7 Jan 2004 04:25:52 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae9wm-0004B1-00 for xcon@ietf.org; Wed, 07 Jan 2004 04:25:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae9ur-000463-00 for xcon@ietf.org; Wed, 07 Jan 2004 04:23:53 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ae9sy-00042K-00 for xcon@ietf.org; Wed, 07 Jan 2004 04:21:57 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i079Lu606027 for ; Wed, 7 Jan 2004 11:21:56 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 11:21:56 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 11:21:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 7 Jan 2004 11:21:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797575@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times thread-index: AcPUd6OlrQOnqZnVR/SrXwuRQ3by2gAh+GVw To: , , X-OriginalArrivalTime: 07 Jan 2004 09:21:55.0690 (UTC) FILETIME=[B18A84A0:01C3D4FF] 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable No, the focus host (conference server) is the one that handles the = reservations. The focus is only created and destroyed by the conference = server according to the start and stop times. /Hisham > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 06.January.2004 19:06 > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > Khartabil Hisham > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hi Petri, > The CPS is a data storage that is used by the focus, so the=20 > focus will have > to handle the reservation > Roni >=20 > -----Original Message----- > From: petri.koskelainen@nokia.com > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; xcon@ietf.org > Sent: 06/01/2004 18:50 > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 > Hi Roni, >=20 > > My opinion is that the conference policy needs only a=20 > > conference duration parameter if any.=20 > > I think that reservation is an external=20 > > application to the focus. According to the conference=20 > > framework the focus is using the information in the=20 > > conference policy server and the focus is=20 > > not the right place for reservation. >=20 > The reservation is sent to CPS, not to focus. > I think it makes sense to have this (repeat time) capability=20 > in protocol > since we need the feature anyway in real-world (either in CPCP > or in some new mystery protocol between the user and the reservation > application). >=20 >=20 >=20 > -- > Petri >=20 >=20 > > Regards > > Roni Even > >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 4:57 PM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Repeat times > >=20 > >=20 > > A conference has start and stop times. Although the current proposed > > solution has repeat times (eg: meeting repeats weekly), there is no > > requirement for such. > >=20 > > Do we see a need for such capability using CPCP? If so, then=20 > > we need to add > > a requirement. >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 7 05:04:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01023 for ; Wed, 7 Jan 2004 05:04:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeAXl-0001iv-MX for xcon-archive@odin.ietf.org; Wed, 07 Jan 2004 05:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07A45dx006619 for xcon-archive@odin.ietf.org; Wed, 7 Jan 2004 05:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeAXk-0001ig-Jf for xcon-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 05:04: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 FAA01020 for ; Wed, 7 Jan 2004 05:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeAXh-0006Sg-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 05:04:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeAVs-0006PN-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 05:02:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeAVU-0006LE-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 05:01:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeAVU-0001cl-Qz; Wed, 07 Jan 2004 05:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeAUg-0001YI-Kl for xcon@optimus.ietf.org; Wed, 07 Jan 2004 05:00:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00922 for ; Wed, 7 Jan 2004 05:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeAUX-0006KV-00 for xcon@ietf.org; Wed, 07 Jan 2004 05:00:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeAT0-00069T-00 for xcon@ietf.org; Wed, 07 Jan 2004 04:59:11 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AeAQs-0005uM-00 for xcon@ietf.org; Wed, 07 Jan 2004 04:56:59 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jan 2004 11:56:27 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , "Even, Roni" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 7 Jan 2004 11:56:24 +0200 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=none autolearn=no version=2.60 Hisham, The conference server is not mentioned in draft-ietf-sipping-conferencing-framework-01. The framework mentioned the conference policy server. As for reservation my view is that reservation is starting an ad-hoc conference when the schedule time has arrived and it should not be part of the conference policy. Reservation is a separate application from the conference policy. I suggest that if you want to address it then we should have a separate element in the frame work which will be a reservation server. Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Wednesday, January 07, 2004 11:22 AM To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times No, the focus host (conference server) is the one that handles the reservations. The focus is only created and destroyed by the conference server according to the start and stop times. /Hisham > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 06.January.2004 19:06 > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; > Khartabil Hisham > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Hi Petri, > The CPS is a data storage that is used by the focus, so the > focus will have > to handle the reservation > Roni > > -----Original Message----- > From: petri.koskelainen@nokia.com > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; xcon@ietf.org > Sent: 06/01/2004 18:50 > Subject: RE: [XCON] CPCP Requirement: Repeat times > > Hi Roni, > > > My opinion is that the conference policy needs only a > > conference duration parameter if any. > > I think that reservation is an external > > application to the focus. According to the conference > > framework the focus is using the information in the > > conference policy server and the focus is > > not the right place for reservation. > > The reservation is sent to CPS, not to focus. > I think it makes sense to have this (repeat time) capability > in protocol > since we need the feature anyway in real-world (either in CPCP > or in some new mystery protocol between the user and the reservation > application). > > > > -- > Petri > > > > Regards > > Roni Even > > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 4:57 PM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > A conference has start and stop times. Although the current proposed > > solution has repeat times (eg: meeting repeats weekly), there is no > > requirement for such. > > > > Do we see a need for such capability using CPCP? If so, then > > we need to add > > a requirement. > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 7 09:44:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12588 for ; Wed, 7 Jan 2004 09:44:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEuk-0006pn-MD for xcon-archive@odin.ietf.org; Wed, 07 Jan 2004 09:44:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Ei6N8026266 for xcon-archive@odin.ietf.org; Wed, 7 Jan 2004 09:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEuk-0006pZ-E0 for xcon-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:44: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 JAA12454 for ; Wed, 7 Jan 2004 09:44:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEui-0006aI-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:44:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEsl-0006M5-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:42:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeEqq-00065c-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEqo-0006h9-Nc; Wed, 07 Jan 2004 09:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEpo-0006dX-Df for xcon@optimus.ietf.org; Wed, 07 Jan 2004 09:39:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11874 for ; Wed, 7 Jan 2004 09:38:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEpm-0005yl-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:38:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEnw-0005lD-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:37:05 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AeEmM-0005YN-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:35:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2004 06:42:57 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i07EZEGN008788; Wed, 7 Jan 2004 06:35:14 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB39833; Wed, 7 Jan 2004 09:35:11 -0500 (EST) Message-ID: <3FFC191F.9080401@cisco.com> Date: Wed, 07 Jan 2004 09:35:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Even, Roni" CC: "'hisham.khartabil@nokia.com'" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: Re: [XCON] CPCP Requirement: Repeat times References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Roni, To me this is splitting hairs. I think it makes sense to include start and stop time(s) in the conference policy - they are quite consistent with other kinds of policy information. How that policy gets acted upon is irrelevant, as long as it does get acted upon - it is an implementation detail. It might be acted upon directly by the policy server, or by a separate conference server, or some other way. The simple fact is that you can influence it by changing the policy using CPCP. Do you really want to standardize another active entity and another protocol just for this? Paul Even, Roni wrote: > Hisham, > > The conference server is not mentioned in > draft-ietf-sipping-conferencing-framework-01. The framework mentioned the > conference policy server. As for reservation my view is that reservation is > starting an ad-hoc conference when the schedule time has arrived and it > should not be part of the conference policy. Reservation is a separate > application from the conference policy. I suggest that if you want to > address it then we should have a separate element in the frame work which > will be a reservation server. > > Roni > > ************************************* > Roni Even > > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, January 07, 2004 11:22 AM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > No, the focus host (conference server) is the one that handles the > reservations. The focus is only created and destroyed by the conference > server according to the start and stop times. > > /Hisham > > >>-----Original Message----- >>From: ext Even, Roni [mailto:roni.even@polycom.co.il] >>Sent: 06.January.2004 19:06 >>To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; >>Khartabil Hisham >>(Nokia-TP/Helsinki); 'xcon@ietf.org ' >>Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> >>Hi Petri, >>The CPS is a data storage that is used by the focus, so the >>focus will have >>to handle the reservation >>Roni >> >>-----Original Message----- >>From: petri.koskelainen@nokia.com >>To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; xcon@ietf.org >>Sent: 06/01/2004 18:50 >>Subject: RE: [XCON] CPCP Requirement: Repeat times >> >>Hi Roni, >> >> >>>My opinion is that the conference policy needs only a >>>conference duration parameter if any. >>>I think that reservation is an external >>>application to the focus. According to the conference >>>framework the focus is using the information in the >>>conference policy server and the focus is >>>not the right place for reservation. >> >>The reservation is sent to CPS, not to focus. >>I think it makes sense to have this (repeat time) capability >>in protocol >>since we need the feature anyway in real-world (either in CPCP >>or in some new mystery protocol between the user and the reservation >>application). >> >> >> >>-- >>Petri >> >> >> >>>Regards >>>Roni Even >>> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>Sent: Monday, December 15, 2003 4:57 PM >>>To: xcon@ietf.org >>>Subject: [XCON] CPCP Requirement: Repeat times >>> >>> >>>A conference has start and stop times. Although the current proposed >>>solution has repeat times (eg: meeting repeats weekly), there is no >>>requirement for such. >>> >>>Do we see a need for such capability using CPCP? If so, then >>>we need to add >>>a requirement. >> > > _______________________________________________ > 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 Jan 7 09:54:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13114 for ; Wed, 7 Jan 2004 09:54:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF4R-0007VU-MG for xcon-archive@odin.ietf.org; Wed, 07 Jan 2004 09:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Es79B028850 for xcon-archive@odin.ietf.org; Wed, 7 Jan 2004 09:54:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF4R-0007VF-GW for xcon-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:54: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 JAA13091 for ; Wed, 7 Jan 2004 09:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeF4P-0007AI-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:54:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeF2Y-00076u-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:52:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeF1R-00072y-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF1T-0007F7-5L; Wed, 07 Jan 2004 09:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF0X-0007CQ-Lf for xcon@optimus.ietf.org; Wed, 07 Jan 2004 09:50: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 JAA12939 for ; Wed, 7 Jan 2004 09:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeF0U-000700-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:50:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEyp-0006vs-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:48:20 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly07a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AeExJ-0006mk-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:46:45 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07a.srv.mailcontrol.com (MailControl) with SMTP id i07Ek6vX012886; Wed, 7 Jan 2004 14:46:06 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Wed, 7 Jan 2004 14:46:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 7 Jan 2004 14:46:08 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B159@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPVLCgJoSq5I0rjSbeIBhjC78e9fgAAFbDA From: "Chris Boulton" To: "Paul Kyzivat" , "Even, Roni" Cc: , , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Paul. We are already in danger of over-complicating the work being done in XCON. There does not seem to me to be any detrimental effects of having this policy information included in CPCP. Chris. =20 >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 07 January 2004 14:35 >To: Even, Roni >Cc: 'hisham.khartabil@nokia.com'; petri.koskelainen@nokia.com; >xcon@ietf.org >Subject: Re: [XCON] CPCP Requirement: Repeat times > >Roni, > >To me this is splitting hairs. I think it makes sense to include start >and stop time(s) in the conference policy - they are quite consistent >with other kinds of policy information. How that policy gets acted upon >is irrelevant, as long as it does get acted upon - it is an >implementation detail. It might be acted upon directly by the policy >server, or by a separate conference server, or some other way. The >simple fact is that you can influence it by changing the policy using CPCP. > >Do you really want to standardize another active entity and another >protocol just for this? > > Paul > >Even, Roni wrote: >> Hisham, >> >> The conference server is not mentioned in >> draft-ietf-sipping-conferencing-framework-01. The framework mentioned the >> conference policy server. As for reservation my view is that reservation >is >> starting an ad-hoc conference when the schedule time has arrived and it >> should not be part of the conference policy. Reservation is a separate >> application from the conference policy. I suggest that if you want to >> address it then we should have a separate element in the frame work which >> will be a reservation server. >> >> Roni >> >> ************************************* >> Roni Even >> >> Polycom Israel >> >> Tel: +972-3-9251200 >> Cell: +972-55-481099 >> email:roni.even@polycom.co.il >> ******************************************* >> >> >> -----Original Message----- >> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >> Sent: Wednesday, January 07, 2004 11:22 AM >> To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org >> Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> >> No, the focus host (conference server) is the one that handles the >> reservations. The focus is only created and destroyed by the conference >> server according to the start and stop times. >> >> /Hisham >> >> >>>-----Original Message----- >>>From: ext Even, Roni [mailto:roni.even@polycom.co.il] >>>Sent: 06.January.2004 19:06 >>>To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; >>>Khartabil Hisham >>>(Nokia-TP/Helsinki); 'xcon@ietf.org ' >>>Subject: RE: [XCON] CPCP Requirement: Repeat times >>> >>> >>>Hi Petri, >>>The CPS is a data storage that is used by the focus, so the >>>focus will have >>>to handle the reservation >>>Roni >>> >>>-----Original Message----- >>>From: petri.koskelainen@nokia.com >>>To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; xcon@ietf.org >>>Sent: 06/01/2004 18:50 >>>Subject: RE: [XCON] CPCP Requirement: Repeat times >>> >>>Hi Roni, >>> >>> >>>>My opinion is that the conference policy needs only a >>>>conference duration parameter if any. >>>>I think that reservation is an external >>>>application to the focus. According to the conference >>>>framework the focus is using the information in the >>>>conference policy server and the focus is >>>>not the right place for reservation. >>> >>>The reservation is sent to CPS, not to focus. >>>I think it makes sense to have this (repeat time) capability >>>in protocol >>>since we need the feature anyway in real-world (either in CPCP >>>or in some new mystery protocol between the user and the reservation >>>application). >>> >>> >>> >>>-- >>>Petri >>> >>> >>> >>>>Regards >>>>Roni Even >>>> >>>>-----Original Message----- >>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>Sent: Monday, December 15, 2003 4:57 PM >>>>To: xcon@ietf.org >>>>Subject: [XCON] CPCP Requirement: Repeat times >>>> >>>> >>>>A conference has start and stop times. Although the current proposed >>>>solution has repeat times (eg: meeting repeats weekly), there is no >>>>requirement for such. >>>> >>>>Do we see a need for such capability using CPCP? If so, then >>>>we need to add >>>>a requirement. >>> >> >> _______________________________________________ >> 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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 7 10:02:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13356 for ; Wed, 7 Jan 2004 10:02:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFCC-0007hx-Vh for xcon-archive@odin.ietf.org; Wed, 07 Jan 2004 10:02:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07F28xO029623 for xcon-archive@odin.ietf.org; Wed, 7 Jan 2004 10:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeFCC-0007hg-PC for xcon-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 10:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13315 for ; Wed, 7 Jan 2004 10:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeFCA-0007SK-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 10:02:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeFAK-0007O1-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 10:00:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeF9B-0007K2-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 09:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF9B-0007Zv-Rl; Wed, 07 Jan 2004 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF8H-0007Yp-0L for xcon@optimus.ietf.org; Wed, 07 Jan 2004 09:58: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 JAA13189 for ; Wed, 7 Jan 2004 09:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeF8E-0007IC-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeF6K-0007EZ-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:56:05 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AeF5B-0007Bl-00 for xcon@ietf.org; Wed, 07 Jan 2004 09:54:54 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jan 2004 16:54:22 +0200 Message-ID: From: "Even, Roni" To: "'Paul Kyzivat'" , "Even, Roni" Cc: "'hisham.khartabil@nokia.com'" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 7 Jan 2004 16:54:14 +0200 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=none autolearn=no version=2.60 Paul, The question is what is the usage for those parameters. A conference has a duration. If you want time for reservation what I claim that this is not enough. The issue of repeat times was mentioned. What about address books so when reserving a conference you can select the participants. What is the semantics of the time, will the server let you know if the reservation is OK when you reserve, will it let you know what are the resource availability be time in the response. What I am saying that just having these two parameter makes sense if you define what they are for, how you use them in CPCP , what will the conference server do with them and what are the response you can expect from the conference policy server. This needs to be defined in order to have consistency between different implementations of conference policy servers. My video is that conference policy has nothing to do with reservation. BTW the 3GPP MRF is only doing ad-hoc and reservation is handled by an application server. Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, January 07, 2004 4:35 PM To: Even, Roni Cc: 'hisham.khartabil@nokia.com'; petri.koskelainen@nokia.com; xcon@ietf.org Subject: Re: [XCON] CPCP Requirement: Repeat times Roni, To me this is splitting hairs. I think it makes sense to include start and stop time(s) in the conference policy - they are quite consistent with other kinds of policy information. How that policy gets acted upon is irrelevant, as long as it does get acted upon - it is an implementation detail. It might be acted upon directly by the policy server, or by a separate conference server, or some other way. The simple fact is that you can influence it by changing the policy using CPCP. Do you really want to standardize another active entity and another protocol just for this? Paul Even, Roni wrote: > Hisham, > > The conference server is not mentioned in > draft-ietf-sipping-conferencing-framework-01. The framework mentioned the > conference policy server. As for reservation my view is that reservation is > starting an ad-hoc conference when the schedule time has arrived and it > should not be part of the conference policy. Reservation is a separate > application from the conference policy. I suggest that if you want to > address it then we should have a separate element in the frame work which > will be a reservation server. > > Roni > > ************************************* > Roni Even > > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, January 07, 2004 11:22 AM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > No, the focus host (conference server) is the one that handles the > reservations. The focus is only created and destroyed by the conference > server according to the start and stop times. > > /Hisham > > >>-----Original Message----- >>From: ext Even, Roni [mailto:roni.even@polycom.co.il] >>Sent: 06.January.2004 19:06 >>To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; >>Khartabil Hisham >>(Nokia-TP/Helsinki); 'xcon@ietf.org ' >>Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> >>Hi Petri, >>The CPS is a data storage that is used by the focus, so the >>focus will have >>to handle the reservation >>Roni >> >>-----Original Message----- >>From: petri.koskelainen@nokia.com >>To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; xcon@ietf.org >>Sent: 06/01/2004 18:50 >>Subject: RE: [XCON] CPCP Requirement: Repeat times >> >>Hi Roni, >> >> >>>My opinion is that the conference policy needs only a >>>conference duration parameter if any. >>>I think that reservation is an external >>>application to the focus. According to the conference >>>framework the focus is using the information in the >>>conference policy server and the focus is >>>not the right place for reservation. >> >>The reservation is sent to CPS, not to focus. >>I think it makes sense to have this (repeat time) capability >>in protocol >>since we need the feature anyway in real-world (either in CPCP >>or in some new mystery protocol between the user and the reservation >>application). >> >> >> >>-- >>Petri >> >> >> >>>Regards >>>Roni Even >>> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>Sent: Monday, December 15, 2003 4:57 PM >>>To: xcon@ietf.org >>>Subject: [XCON] CPCP Requirement: Repeat times >>> >>> >>>A conference has start and stop times. Although the current proposed >>>solution has repeat times (eg: meeting repeats weekly), there is no >>>requirement for such. >>> >>>Do we see a need for such capability using CPCP? If so, then >>>we need to add >>>a requirement. >> > > _______________________________________________ > 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 Jan 7 11:26:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17491 for ; Wed, 7 Jan 2004 11:26:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGVR-0002r5-QE for xcon-archive@odin.ietf.org; Wed, 07 Jan 2004 11:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07GQ5LR010969 for xcon-archive@odin.ietf.org; Wed, 7 Jan 2004 11:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGVR-0002qq-LM for xcon-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 11:26: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 LAA17486 for ; Wed, 7 Jan 2004 11:26:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGVQ-0003rP-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 11:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGTf-0003op-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 11:24:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeGSS-0003kl-00 for xcon-web-archive@ietf.org; Wed, 07 Jan 2004 11:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGSS-0002m9-KN; Wed, 07 Jan 2004 11:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGRc-0002kw-SI for xcon@optimus.ietf.org; Wed, 07 Jan 2004 11:22:10 -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 LAA17363 for ; Wed, 7 Jan 2004 11:22:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGRY-0003i2-00 for xcon@ietf.org; Wed, 07 Jan 2004 11:22:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGPk-0003es-00 for xcon@ietf.org; Wed, 07 Jan 2004 11:20:12 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AeGNz-0003WY-00 for xcon@ietf.org; Wed, 07 Jan 2004 11:18:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2004 08:25:32 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i07GHlGN017720; Wed, 7 Jan 2004 08:17:48 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB50242; Wed, 7 Jan 2004 11:17:45 -0500 (EST) Message-ID: <3FFC3129.1020307@cisco.com> Date: Wed, 07 Jan 2004 11:17:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Even, Roni" CC: "'hisham.khartabil@nokia.com'" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: Re: [XCON] CPCP Requirement: Repeat times References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Even, Roni wrote: > Paul, > The question is what is the usage for those parameters. A conference has a > duration. If you want time for reservation what I claim that this is not > enough. The issue of repeat times was mentioned. That seems like just another representation for multiple start/stop times. > What about address books so > when reserving a conference you can select the participants. What about them? That seems entirely irrelevant to this discussion. If you have address books, then use them with some tool that creates your conference policy before submitting it via CPCP. > What is the > semantics of the time, will the server let you know if the reservation is > OK when you reserve, will it let you know what are the resource availability > be time in the response. It seems logical to me that the policy server should refuse to accept the policy if some attribute in it is unacceptable. A situation where the resources aren't available at the specified times seems to fall into that category. If you want a tool that can help you select a time when the resources are available, that is a different story. I think it falls into the category of a tool for creating policy. > What I am saying that just having these two > parameter makes sense if you define what they are for, how you use them in > CPCP , what will the conference server do with them and what are the > response you can expect from the conference policy server. This needs to be > defined in order to have consistency between different implementations of > conference policy servers. Well yes, clearly there is some amount of definition that is currently lacking. But it doesn't seem like so much. > My video is that conference policy has nothing to do with reservation. BTW > the 3GPP MRF is only doing ad-hoc and reservation is handled by an > application server. Just a different way to slice the pie. In any case, there is probably a role for an application server that provides a UI for creating conference policy. I would expect such things to be layered on what is being defined here, and not to be standardized. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Jan 12 16:08:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19461 for ; Mon, 12 Jan 2004 16:08:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9I4-0005L3-O9 for xcon-archive@odin.ietf.org; Mon, 12 Jan 2004 16:08:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CL84Er020515 for xcon-archive@odin.ietf.org; Mon, 12 Jan 2004 16:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9I3-0005Ko-EM for xcon-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:08: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 QAA19400 for ; Mon, 12 Jan 2004 16:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9I1-0007l4-00 for xcon-web-archive@ietf.org; Mon, 12 Jan 2004 16:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9G1-0007dc-00 for xcon-web-archive@ietf.org; Mon, 12 Jan 2004 16:05:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9E8-0007Yy-00 for xcon-web-archive@ietf.org; Mon, 12 Jan 2004 16:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9E9-0004pO-DN; Mon, 12 Jan 2004 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9DJ-0004ol-2r for xcon@optimus.ietf.org; Mon, 12 Jan 2004 16:03:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18932; Mon, 12 Jan 2004 16:03:06 -0500 (EST) Message-Id: <200401122103.QAA18932@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: xcon@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 12 Jan 2004 16:03:06 -0500 Subject: [XCON] I-D ACTION: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.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 Floor Control Protocol Author(s) : H. Schulzrinne Filename : draft-ietf-xcon-floor-control-req-00.txt Pages : 16 Date : 2004-1-12 This document defines the requirements for floor control in a multi-party conference environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-floor-control-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-floor-control-req-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-floor-control-req-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-1-12154050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-floor-control-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-floor-control-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-12154050.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 13 22:07:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29821 for ; Tue, 13 Jan 2004 22:07:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbMv-0002Yk-To for xcon-archive@odin.ietf.org; Tue, 13 Jan 2004 22:06:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E36v2j009832 for xcon-archive@odin.ietf.org; Tue, 13 Jan 2004 22:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbMv-0002YV-MT for xcon-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 22:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29685 for ; Tue, 13 Jan 2004 22:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgbMs-0006WM-00 for xcon-web-archive@ietf.org; Tue, 13 Jan 2004 22:06:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgbL2-0006L2-00 for xcon-web-archive@ietf.org; Tue, 13 Jan 2004 22:05:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AgbJ1-0006Ey-00 for xcon-web-archive@ietf.org; Tue, 13 Jan 2004 22:02:55 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Agb5c-00042z-1c for xcon-web-archive@ietf.org; Tue, 13 Jan 2004 21:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agb5Y-0001wY-Ql; Tue, 13 Jan 2004 21:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agb5C-0001vi-J5 for xcon@optimus.ietf.org; Tue, 13 Jan 2004 21:48:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28860 for ; Tue, 13 Jan 2004 21:48:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agb59-0005RD-00 for xcon@ietf.org; Tue, 13 Jan 2004 21:48:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agb3Y-0005Mf-00 for xcon@ietf.org; Tue, 13 Jan 2004 21:46:57 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Agb2J-0005H5-00 for xcon@ietf.org; Tue, 13 Jan 2004 21:45:39 -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.0) with ESMTP id i0E2j6C22939 for ; Tue, 13 Jan 2004 20:45:07 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 16:54:53 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFAC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rosen, Brian'" , "'Even, Roni'" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 13 Jan 2004 16:54:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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=none autolearn=no version=2.60 I do not remember seeing the existence of this separate protocol in any of the conferencing documents so far (either in SIPPING or XCON). (If I am wrong then pointers gratefully received). If it exists, then I think we should clearly identify what its scope is, if only to aid the discussion of what the other protocols may or may not do. We clearly need a start and stop time for conferencing. At the moment the only protocol it can be in is the CPCP. If we are going to have an informed discussion about why it is not in CPCP we need to understand clearly what the alternative protocol is. regards Keith > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 06 January 2004 14:14 > To: 'Even, Roni' > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > I don't like this idea because I think that we need a > standardized interface > for scheduling and "external application server" sounds very > proprietary to > me. I guess I could be convinced we need a separate interface, with a > separate protocol (maybe it could be iCal), but I'm not yet convinced > just specifying a start time in the future isn't a sufficient > reservation > mechanism. > > Brian > > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, January 06, 2004 7:22 AM > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > Brian, > My suggestion is not to have reservation in the conference policy. The > conference policy is used by the focus according to the > conference framework > and the focus is not the place for handling reservation. I think that > reservation is handled by an external application server that > will start the > conference using CPCP at the time when the conference > scheduled time has > arrived. The focus may use the conference duration > information in order to > notify the participants that it the conference end-time is coming and > terminate the conference. Extension of the should be done > using CPCP either > by the participant or an application server. > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, December 15, 2003 4:25 PM > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > Again, I'm worried about "privileged users". I think we need > to finish > some discussions we started a while ago that essentially are > semantics. > What is an "inactivated" conference, and how does it differ from a > conference that can be re-instantiated (a weekly meeting for example)? > > Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > This is in reference to requirement REQ-B9 in > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-B9: It MUST be possible to inactive a conference for defined > > period of time. > > > > There are start and stop times for a conference. A conference > > might live for days, weeks or even months. Should a > > conference policy, using CPCP, allow a privileged user to > > de-activate a conference for a period of time within the > > start and stop times of a conference? Examples are > > administrator is performing some maintenance. > > > > Regards, > > Hisham > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 14 03:34:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05199 for ; Wed, 14 Jan 2004 03:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AggT7-0000aX-G9 for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 03:33:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E8XfLa002261 for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 03:33:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AggT7-0000aO-4H for xcon-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 03:33:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05191 for ; Wed, 14 Jan 2004 03:33:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AggSz-0002Hg-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 03:33:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AggPy-0002CA-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 03:30:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AggM0-00027Q-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 03:26:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AggLh-0000EQ-5U; Wed, 14 Jan 2004 03:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AggLZ-0000ED-Uy for xcon@optimus.ietf.org; Wed, 14 Jan 2004 03:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05063 for ; Wed, 14 Jan 2004 03:25:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AggLE-00025r-00 for xcon@ietf.org; Wed, 14 Jan 2004 03:25:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AggIG-00020x-00 for xcon@ietf.org; Wed, 14 Jan 2004 03:22:29 -0500 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 1AggFH-0001wF-00 for xcon@ietf.org; Wed, 14 Jan 2004 03:19:23 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jan 2004 10:18:14 +0200 Message-ID: From: "Even, Roni" To: "'Drage, Keith (Keith)'" , "'Rosen, Brian'" , "Even, Roni" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Wed, 14 Jan 2004 10:18:13 +0200 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=none autolearn=no version=2.60 Hi, I did not think that the conference work was also addressing reservation systems and that is why it is not clear to me why we need the start and stop time of a conference in CPCP. If conference reservation is in the scope of the work then we need some more parameters in CPCP for supporting it. We also need to understand what it may support for example can I give a start time in 2050, what about next month, can I learn from CPCP what resources are available at a specific time. If the start and stop time are only what they sound and the application is handled by an application server then what is the difference between having a start and stop time and letting the application server start the conference when the scheduled time has arrived Thanks Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Tuesday, January 13, 2004 6:55 PM To: 'Rosen, Brian'; 'Even, Roni' Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference I do not remember seeing the existence of this separate protocol in any of the conferencing documents so far (either in SIPPING or XCON). (If I am wrong then pointers gratefully received). If it exists, then I think we should clearly identify what its scope is, if only to aid the discussion of what the other protocols may or may not do. We clearly need a start and stop time for conferencing. At the moment the only protocol it can be in is the CPCP. If we are going to have an informed discussion about why it is not in CPCP we need to understand clearly what the alternative protocol is. regards Keith > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 06 January 2004 14:14 > To: 'Even, Roni' > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > I don't like this idea because I think that we need a > standardized interface > for scheduling and "external application server" sounds very > proprietary to > me. I guess I could be convinced we need a separate interface, with a > separate protocol (maybe it could be iCal), but I'm not yet convinced > just specifying a start time in the future isn't a sufficient > reservation > mechanism. > > Brian > > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, January 06, 2004 7:22 AM > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > Brian, > My suggestion is not to have reservation in the conference policy. The > conference policy is used by the focus according to the > conference framework > and the focus is not the place for handling reservation. I think that > reservation is handled by an external application server that > will start the > conference using CPCP at the time when the conference > scheduled time has > arrived. The focus may use the conference duration > information in order to > notify the participants that it the conference end-time is coming and > terminate the conference. Extension of the should be done > using CPCP either > by the participant or an application server. > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, December 15, 2003 4:25 PM > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > Again, I'm worried about "privileged users". I think we need > to finish > some discussions we started a while ago that essentially are > semantics. > What is an "inactivated" conference, and how does it differ from a > conference that can be re-instantiated (a weekly meeting for example)? > > Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > This is in reference to requirement REQ-B9 in > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-B9: It MUST be possible to inactive a conference for defined > > period of time. > > > > There are start and stop times for a conference. A conference > > might live for days, weeks or even months. Should a > > conference policy, using CPCP, allow a privileged user to > > de-activate a conference for a period of time within the > > start and stop times of a conference? Examples are > > administrator is performing some maintenance. > > > > Regards, > > Hisham > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 14 06:56:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14148 for ; Wed, 14 Jan 2004 06:56:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjdN-0002hs-4l for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 06:56:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EBuTSY010398 for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 06:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjdL-0002hY-IC for xcon-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 06:56:27 -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 GAA14021 for ; Wed, 14 Jan 2004 06:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgjdH-0007CG-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 06:56:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgjaX-0006lt-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 06:53:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgjY4-0006Hy-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 06:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjY7-0002KU-5M; Wed, 14 Jan 2004 06:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjXl-0002Ht-A7 for xcon@optimus.ietf.org; Wed, 14 Jan 2004 06:50:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13271 for ; Wed, 14 Jan 2004 06:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgjXh-0006Cm-00 for xcon@ietf.org; Wed, 14 Jan 2004 06:50:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgjTn-0005S5-00 for xcon@ietf.org; Wed, 14 Jan 2004 06:46:38 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AgjKj-0004Zh-00 for xcon@ietf.org; Wed, 14 Jan 2004 06:37:13 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0EBZur02364 for ; Wed, 14 Jan 2004 05:36:02 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 11:35:53 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFAF@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Even, Roni'" , "Drage, Keith (Keith)" , "'Rosen, Brian'" Cc: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Wed, 14 Jan 2004 11:35:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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=none autolearn=no version=2.60 May I was not so clear in my original mail. I do not propose we define a reservation protocol. However something like the framework document should clearly identify that things like reservation protocols may exist (if indeed they do), and define its scope. In considering requirements for CPCP we can then evaluate whether they are in scope for CPCP or in scope for the reservation protocol, rather than seemingly a more ad-hoc judgement of whether it is nice to put it in CPCP. regards Keith > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 14 January 2004 08:18 > To: 'Drage, Keith (Keith)'; 'Rosen, Brian'; Even, Roni > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > Hi, > > I did not think that the conference work was also addressing > reservation > systems and that is why it is not clear to me why we need the > start and stop > time of a conference in CPCP. If conference reservation is in > the scope of > the work then we need some more parameters in CPCP for > supporting it. We > also need to understand what it may support for example can I > give a start > time in 2050, what about next month, can I learn from CPCP > what resources > are available at a specific time. If the start and stop time > are only what > they sound and the application is handled by an application > server then what > is the difference between having a start and stop time and letting the > application server start the conference when the scheduled > time has arrived > Thanks > Roni Even > > ************************************* > Roni Even > > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, January 13, 2004 6:55 PM > To: 'Rosen, Brian'; 'Even, Roni' > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > I do not remember seeing the existence of this separate > protocol in any of > the conferencing documents so far (either in SIPPING or > XCON). (If I am > wrong then pointers gratefully received). If it exists, then > I think we > should clearly identify what its scope is, if only to aid the > discussion of > what the other protocols may or may not do. > > We clearly need a start and stop time for conferencing. At > the moment the > only protocol it can be in is the CPCP. If we are going to > have an informed > discussion about why it is not in CPCP we need to understand > clearly what > the alternative protocol is. > > regards > > Keith > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 06 January 2004 14:14 > > To: 'Even, Roni' > > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > I don't like this idea because I think that we need a > > standardized interface > > for scheduling and "external application server" sounds very > > proprietary to > > me. I guess I could be convinced we need a separate > interface, with a > > separate protocol (maybe it could be iCal), but I'm not yet > convinced > > just specifying a start time in the future isn't a sufficient > > reservation > > mechanism. > > > > Brian > > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tuesday, January 06, 2004 7:22 AM > > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Brian, > > My suggestion is not to have reservation in the conference > policy. The > > conference policy is used by the focus according to the > > conference framework > > and the focus is not the place for handling reservation. I > think that > > reservation is handled by an external application server that > > will start the > > conference using CPCP at the time when the conference > > scheduled time has > > arrived. The focus may use the conference duration > > information in order to > > notify the participants that it the conference end-time is > coming and > > terminate the conference. Extension of the should be done > > using CPCP either > > by the participant or an application server. > > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Monday, December 15, 2003 4:25 PM > > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Again, I'm worried about "privileged users". I think we need > > to finish > > some discussions we started a while ago that essentially are > > semantics. > > What is an "inactivated" conference, and how does it differ from a > > conference that can be re-instantiated (a weekly meeting > for example)? > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 7:57 AM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > This is in reference to requirement REQ-B9 in > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > REQ-B9: It MUST be possible to inactive a conference for defined > > period of time. > > > > There are start and stop times for a conference. A conference > > might live for days, weeks or even months. Should a > > conference policy, using CPCP, allow a privileged user to > > de-activate a conference for a period of time within the > > start and stop times of a conference? Examples are > > administrator is performing some maintenance. > > > > Regards, > > Hisham > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 14 10:07:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21785 for ; Wed, 14 Jan 2004 10:07:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmbV-000411-DT for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 10:06:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EF6jpE015429 for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 10:06:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmbV-00040m-7R for xcon-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 10:06:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21728 for ; Wed, 14 Jan 2004 10:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgmbT-0007G0-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 10:06:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgmaY-0007Ex-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 10:05:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgmZq-0007Dy-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 10:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmZr-0003y6-AV; Wed, 14 Jan 2004 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmYs-0003wy-Aw for xcon@optimus.ietf.org; Wed, 14 Jan 2004 10:04: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 KAA21412 for ; Wed, 14 Jan 2004 10:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgmYq-0007Ag-00 for xcon@ietf.org; Wed, 14 Jan 2004 10:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgmXq-00077e-00 for xcon@ietf.org; Wed, 14 Jan 2004 10:02:59 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AgmXU-00074f-00 for xcon@ietf.org; Wed, 14 Jan 2004 10:02:36 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0EF21LE024223; Wed, 14 Jan 2004 10:02:01 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWF22548; Wed, 14 Jan 2004 07:01:59 -0800 (PST) Message-Id: <4.3.2.7.2.20040114095511.00b26148@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jan 2004 10:01:59 -0500 To: "Even, Roni" From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: de-activating a conference Cc: "'Drage, Keith (Keith)'" , "'Rosen, Brian'" , "Even, Roni" , "'hisham.khartabil@nokia.com'" , xcon@ietf.org In-Reply-To: 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=none autolearn=no version=2.60 Roni, I am still a little fuzzy on what is/is not being addressed. For example, if the conference moderator wanted to create breakout sessions with defined start and stop times with assigned participants, could this be setup with CPCP such that the breakouts are created in 10 minutes, then terminate after another 10 minutes? Note, for certain purposes, one may want to disallow independent sidebars using that conference server. Is this possible? Mike At 10:18 AM 1/14/2004 +0200, Even, Roni wrote: >Hi, > >I did not think that the conference work was also addressing reservation >systems and that is why it is not clear to me why we need the start and stop >time of a conference in CPCP. If conference reservation is in the scope of >the work then we need some more parameters in CPCP for supporting it. We >also need to understand what it may support for example can I give a start >time in 2050, what about next month, can I learn from CPCP what resources >are available at a specific time. If the start and stop time are only what >they sound and the application is handled by an application server then what >is the difference between having a start and stop time and letting the >application server start the conference when the scheduled time has arrived >Thanks >Roni Even > >************************************* >Roni Even > >Polycom Israel > >Tel: +972-3-9251200 >Cell: +972-55-481099 >email:roni.even@polycom.co.il >******************************************* > > >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com] >Sent: Tuesday, January 13, 2004 6:55 PM >To: 'Rosen, Brian'; 'Even, Roni' >Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org >Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > >I do not remember seeing the existence of this separate protocol in any of >the conferencing documents so far (either in SIPPING or XCON). (If I am >wrong then pointers gratefully received). If it exists, then I think we >should clearly identify what its scope is, if only to aid the discussion of >what the other protocols may or may not do. > >We clearly need a start and stop time for conferencing. At the moment the >only protocol it can be in is the CPCP. If we are going to have an informed >discussion about why it is not in CPCP we need to understand clearly what >the alternative protocol is. > >regards > >Keith > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 06 January 2004 14:14 > > To: 'Even, Roni' > > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > I don't like this idea because I think that we need a > > standardized interface > > for scheduling and "external application server" sounds very > > proprietary to > > me. I guess I could be convinced we need a separate interface, with a > > separate protocol (maybe it could be iCal), but I'm not yet convinced > > just specifying a start time in the future isn't a sufficient > > reservation > > mechanism. > > > > Brian > > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tuesday, January 06, 2004 7:22 AM > > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Brian, > > My suggestion is not to have reservation in the conference policy. The > > conference policy is used by the focus according to the > > conference framework > > and the focus is not the place for handling reservation. I think that > > reservation is handled by an external application server that > > will start the > > conference using CPCP at the time when the conference > > scheduled time has > > arrived. The focus may use the conference duration > > information in order to > > notify the participants that it the conference end-time is coming and > > terminate the conference. Extension of the should be done > > using CPCP either > > by the participant or an application server. > > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Monday, December 15, 2003 4:25 PM > > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Again, I'm worried about "privileged users". I think we need > > to finish > > some discussions we started a while ago that essentially are > > semantics. > > What is an "inactivated" conference, and how does it differ from a > > conference that can be re-instantiated (a weekly meeting for example)? > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:57 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > This is in reference to requirement REQ-B9 in > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-B9: It MUST be possible to inactive a conference for defined > > > period of time. > > > > > > There are start and stop times for a conference. A conference > > > might live for days, weeks or even months. Should a > > > conference policy, using CPCP, allow a privileged user to > > > de-activate a conference for a period of time within the > > > start and stop times of a conference? Examples are > > > administrator is performing some maintenance. > > > > > > Regards, > > > Hisham > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 14 11:53:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27491 for ; Wed, 14 Jan 2004 11:53:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgoG9-0002IQ-1J for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 11:52:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EGqno1008820 for xcon-archive@odin.ietf.org; Wed, 14 Jan 2004 11:52:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgoG8-0002IB-C5 for xcon-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 11:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27466 for ; Wed, 14 Jan 2004 11:52:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgoG7-0004Vu-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 11:52:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgoFK-0004SN-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 11:51:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgoEQ-0004Mx-00 for xcon-web-archive@ietf.org; Wed, 14 Jan 2004 11:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgoEQ-0002CA-I2; Wed, 14 Jan 2004 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmlD-0004k8-Nj for xcon@optimus.ietf.org; Wed, 14 Jan 2004 10:16:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22807 for ; Wed, 14 Jan 2004 10:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgmlB-0007Yt-00 for xcon@ietf.org; Wed, 14 Jan 2004 10:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgmkJ-0007WO-00 for xcon@ietf.org; Wed, 14 Jan 2004 10:15:52 -0500 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 1AgmjL-0007Ru-00 for xcon@ietf.org; Wed, 14 Jan 2004 10:14:52 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Jan 2004 17:14:16 +0200 Message-ID: From: "Even, Roni" To: "'Michael Hammer'" , "Even, Roni" Cc: "'Drage, Keith (Keith)'" , "'Rosen, Brian'" , "Even, Roni" , "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Wed, 14 Jan 2004 17:14:15 +0200 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=none autolearn=no version=2.60 Mike, This is a service that is not available by all conference bridges and will need to be implemented by an application server that will use CPCP to start the breakout session and invite the participants to it. What happens in the end of the breakout session, does the conference bridge bring all to the main conference, can the moderator extend it,, all these are applications and not part of the conference service in my view Roni -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Wednesday, January 14, 2004 5:02 PM To: Even, Roni Cc: 'Drage, Keith (Keith)'; 'Rosen, Brian'; Even, Roni; 'hisham.khartabil@nokia.com'; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: de-activating a conference Roni, I am still a little fuzzy on what is/is not being addressed. For example, if the conference moderator wanted to create breakout sessions with defined start and stop times with assigned participants, could this be setup with CPCP such that the breakouts are created in 10 minutes, then terminate after another 10 minutes? Note, for certain purposes, one may want to disallow independent sidebars using that conference server. Is this possible? Mike At 10:18 AM 1/14/2004 +0200, Even, Roni wrote: >Hi, > >I did not think that the conference work was also addressing reservation >systems and that is why it is not clear to me why we need the start and stop >time of a conference in CPCP. If conference reservation is in the scope of >the work then we need some more parameters in CPCP for supporting it. We >also need to understand what it may support for example can I give a start >time in 2050, what about next month, can I learn from CPCP what resources >are available at a specific time. If the start and stop time are only what >they sound and the application is handled by an application server then what >is the difference between having a start and stop time and letting the >application server start the conference when the scheduled time has arrived >Thanks >Roni Even > >************************************* >Roni Even > >Polycom Israel > >Tel: +972-3-9251200 >Cell: +972-55-481099 >email:roni.even@polycom.co.il >******************************************* > > >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com] >Sent: Tuesday, January 13, 2004 6:55 PM >To: 'Rosen, Brian'; 'Even, Roni' >Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org >Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > >I do not remember seeing the existence of this separate protocol in any of >the conferencing documents so far (either in SIPPING or XCON). (If I am >wrong then pointers gratefully received). If it exists, then I think we >should clearly identify what its scope is, if only to aid the discussion of >what the other protocols may or may not do. > >We clearly need a start and stop time for conferencing. At the moment the >only protocol it can be in is the CPCP. If we are going to have an informed >discussion about why it is not in CPCP we need to understand clearly what >the alternative protocol is. > >regards > >Keith > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 06 January 2004 14:14 > > To: 'Even, Roni' > > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > I don't like this idea because I think that we need a > > standardized interface > > for scheduling and "external application server" sounds very > > proprietary to > > me. I guess I could be convinced we need a separate interface, with a > > separate protocol (maybe it could be iCal), but I'm not yet convinced > > just specifying a start time in the future isn't a sufficient > > reservation > > mechanism. > > > > Brian > > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tuesday, January 06, 2004 7:22 AM > > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Brian, > > My suggestion is not to have reservation in the conference policy. The > > conference policy is used by the focus according to the > > conference framework > > and the focus is not the place for handling reservation. I think that > > reservation is handled by an external application server that > > will start the > > conference using CPCP at the time when the conference > > scheduled time has > > arrived. The focus may use the conference duration > > information in order to > > notify the participants that it the conference end-time is coming and > > terminate the conference. Extension of the should be done > > using CPCP either > > by the participant or an application server. > > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Monday, December 15, 2003 4:25 PM > > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > Again, I'm worried about "privileged users". I think we need > > to finish > > some discussions we started a while ago that essentially are > > semantics. > > What is an "inactivated" conference, and how does it differ from a > > conference that can be re-instantiated (a weekly meeting for example)? > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:57 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > This is in reference to requirement REQ-B9 in > > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-B9: It MUST be possible to inactive a conference for defined > > > period of time. > > > > > > There are start and stop times for a conference. A conference > > > might live for days, weeks or even months. Should a > > > conference policy, using CPCP, allow a privileged user to > > > de-activate a conference for a period of time within the > > > start and stop times of a conference? Examples are > > > administrator is performing some maintenance. > > > > > > Regards, > > > Hisham > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 20 11:05:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08100 for ; Tue, 20 Jan 2004 11:05:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN0-000533-OS for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KG4oWU019399 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN0-00052o-IW for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:04:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08030 for ; Tue, 20 Jan 2004 11:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyMy-0001PV-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:04:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyM8-0001KB-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:03:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiyLD-0001DH-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyLF-0004mY-2K; Tue, 20 Jan 2004 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyKp-0004lp-2u for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:02:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07760 for ; Tue, 20 Jan 2004 11:02:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyKm-0001Ak-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:02:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyJo-00016Y-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:33 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AiyJR-000137-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:09 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18441; Tue, 20 Jan 2004 11:03:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Anonymous participants Date: Tue, 20 Jan 2004 11:00:38 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A05A@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Anonymous participants Thread-Index: AcPGIWdOOLTh0ox+TUOV5H5uMuZlvwAEwQUABi/8xuA= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable What if we bring back a concept from your first posting. If = participants can be Anonymous to the moderator, is there any reason not = to have an "anonymous" user? That is, they log in as "anonymous". This = makes the anonymity issue purely a local matter. No changes or special = requirements in the protocol needed. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Friday, December 19, 2003 8:38 AM > To: drage@lucent.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Anonymous participants >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 19.December.2003 13:14 > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Anonymous participants > >=20 > >=20 > > In answer to the questions below: > >=20 > > If we are going to allow anonymous users, then CPCP should be=20 > > allowed to set whether they are allowed for a particular=20 > > conference or not. I see no mileage in a default. > >=20 > > As regards the type of anonymous user, I see no point in 1),=20 > > but 2) should be allowed. Note that anonymity of identity is=20 > > more than the From header, in that you also need to cover the=20 > > interrelation with RFC 3325 identities and the sip-identity=20 > > draft, and/or a specification of privacy of various kinds=20 > > according to RFC 3323 (header privacy should kill the From header). > >=20 > > In respect of both these, we need to clearly indicate who can=20 > > see, and who cannot see these identities. I assume that=20 > > primarily the requirement applies to other participants - but=20 > > are there special rights for the conference owner - the one=20 > > able to do the CPCP. >=20 > I think it should be one or the other. Either complete=20 > anonymity from users, including moderator, or excluding moderator. >=20 > For the sake of simplicity (and not to start the privileges=20 > discussion again), I would choose complete anonymity,=20 > including anonymity from moderators. >=20 > /Hisham >=20 > >=20 > > regards > >=20 > > Keith > >=20 > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > >=20 > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: 15 December 2003 12:54 > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: Anonymous participants > > >=20 > > >=20 > > > This is the first of a series of emails discussing Conference=20 > > > Policy Requirements. Your engagement is appreciated. > > >=20 > > > This is in reference to requirements REQ-A6 and REQ-E9 in=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > >=20 > > > REQ-A6: It SHOULD be possible to anonymously participate in a > > > conference. > > >=20 > > > REQ-E9: It MUST be possible to allow and disallow anonymous > > > membership in a conference. > > >=20 > > > Should a conference policy, using CPCP, specify if anonymous=20 > > > participants are allowed to join a conference? Or should this=20 > > > be a local policy at the server? > > >=20 > > > There are 2 types of anonymous participants: > > >=20 > > > 1. ones that joins a conference using a http digest username=20 > > > of "anonymous" and no password > > > 2. ones that join with a proper username and password, but=20 > > > hide their identity using anonynous@somewhere.com in the=20 > > > From-header of a SIP INVITE. The conference state package=20 > > > notifications shows them as anonymous participants. > > >=20 > > > I don't think we need to allow 1. Either a conference=20 > > > requires everyone to know the username and password of the=20 > > > conference, or does not require digest authentication at all. > > >=20 > > > 2 can be provided, but we need consensus that this is a=20 > > > useful feature. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 20 11:05:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08103 for ; Tue, 20 Jan 2004 11:05:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN1-00053T-I9 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KG4po9019419 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN1-000538-C6 for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:04:51 -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 LAA08028 for ; Tue, 20 Jan 2004 11:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyMx-0001PQ-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:04:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyM7-0001K1-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:03:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiyLD-0001DG-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyLF-0004mg-BC; Tue, 20 Jan 2004 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyKq-0004lu-I8 for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:02:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07763 for ; Tue, 20 Jan 2004 11:02:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyKo-0001Ax-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:02:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyJp-00016i-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:34 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AiyJS-000137-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:10 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18441; Tue, 20 Jan 2004 11:03:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Tue, 20 Jan 2004 11:00:39 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A05C@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPGIWcIlTiXGJmISm6SBXk6+COhvwY1RK8A From: "Eric Burger" To: Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Would Legal Intercept be in or out? E.g., hidden participants that = CANNOT be known. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, December 19, 2003 6:14 AM > To: hisham.khartabil@nokia.com; mhammer@cisco.com > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > I believe hidden users are appropriate. >=20 > I do not believe that this adds complexity to the=20 > specifications (particularly to the specification of CPCP),=20 > so I see no need to make it a DEFER as far as the=20 > specifications are concerned. It may add complexity to the=20 > implementation, so I am quite happy to see it a MAY in the=20 > requirements, so that it is optional to implement. >=20 > As regards the legal implications of hidden users, then yes,=20 > there may be priveleged users that are able to request the=20 > identity of hidden users (along with an indication that they=20 > are hidden). This of course requires the enabling of such a=20 > privileged user in the first place. >=20 > Secondly, it may not be necessary to identify hidden users,=20 > but merely that there are hidden users in the conference (in=20 > addition to any that may have made themselves visible). Some=20 > countries require some form of tone or announcement on voice=20 > conferences when someone else is listening in. They also=20 > require an announcement or other indication in the call is=20 > being recorded. >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: 15 December 2003 16:29 > > To: mhammer@cisco.com > > Cc: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext Michael Hammer [mailto:mhammer@cisco.com] > > > Sent: 15.December.2003 18:17 > > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > > Cc: xcon@ietf.org > > > Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > >=20 > > >=20 > > > Related to this is there a requirement that, while not=20 > > revealing the=20 > > > identity of a hidden user, the conference policy contains=20 > > > state indication=20 > > > about either the presence of hidden users, or the=20 > > > possibility/preclusion=20 > > > that such hidden users may be present? > > >=20 > > > I am anticipating that: > > > 1) Laws may exist that require notification of such. > >=20 > > That's a good point. This might require changes to the=20 > > conference event package to indicate if there are hidden=20 > > participants or not, and if so, how many. > >=20 > > The question remain: is there a need for such a feature (to=20 > > hide users?)? > >=20 > > Regards, > > Hisham > >=20 > > > 2) In some conferences, participants may want technical=20 > > > assurance that=20 > > > hidden users are not possible before they speak. > > >=20 > > > Mike > > >=20 > > >=20 > > > At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > > >This is in reference to requirements REQ-A7 and REQ-E10 in=20 > > >=20 > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-A7: It SHOULD be possible to participate in a=20 > conference as a > > > hidden user. Hidden user is present in a conference, but=20 > > his presence > > > is not revealed. > > > > > > REQ-E10: It MUST be possible to allow and disallow=20 > > hidden membership > > > in a conference. > > > > > >Should a conference policy, using CPCP, specify if a user=20 > > can be hidden?=20 > > >This means that the conference state package does not report the=20 > > >participation on the hidden user. CPCP is used to identify=20 > > which users are=20 > > >hidden. The list of hidden users is only manipulated by a=20 > > privileged user=20 > > >such as the moderator. > > > > > >Regards, > > >Hisham > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 20 11:05:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08119 for ; Tue, 20 Jan 2004 11:05:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN1-00053c-JC for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KG4pBj019433 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN1-000537-C0 for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:04:51 -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 LAA08033 for ; Tue, 20 Jan 2004 11:04:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyMy-0001Pa-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:04:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyM9-0001KK-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:03:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiyLD-0001DJ-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyLF-0004n4-Ju; Tue, 20 Jan 2004 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyKr-0004lz-43 for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:02:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07766 for ; Tue, 20 Jan 2004 11:02:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyKo-0001B2-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:02:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyJq-00016s-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:35 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AiyJT-000137-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:11 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18441; Tue, 20 Jan 2004 11:03:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 20 Jan 2004 11:00:39 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A05D@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPVBUoCgM0ehvpfSxOikskifw/TkwJ8ajmw From: "Eric Burger" To: "Even, Roni" , , , 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable For that matter, is there a use case for end points (XCON) doing such = complicated scheduling? Why don't we just take the bridge out of = service? Wow! Agreeing with Roni twice in one day!!! > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Wednesday, January 07, 2004 4:56 AM > To: 'hisham.khartabil@nokia.com'; Even, Roni; > petri.koskelainen@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hisham, >=20 > The conference server is not mentioned in > draft-ietf-sipping-conferencing-framework-01. The framework=20 > mentioned the > conference policy server. As for reservation my view is that=20 > reservation is > starting an ad-hoc conference when the schedule time has=20 > arrived and it > should not be part of the conference policy. Reservation is a separate > application from the conference policy. I suggest that if you want to > address it then we should have a separate element in the=20 > frame work which > will be a reservation server. >=20 > Roni >=20 > ************************************* > Roni Even >=20 > Polycom Israel >=20 > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >=20 >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, January 07, 2004 11:22 AM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > No, the focus host (conference server) is the one that handles the > reservations. The focus is only created and destroyed by the=20 > conference > server according to the start and stop times. >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 06.January.2004 19:06 > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > Khartabil Hisham > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Hi Petri, > > The CPS is a data storage that is used by the focus, so the=20 > > focus will have > > to handle the reservation > > Roni > >=20 > > -----Original Message----- > > From: petri.koskelainen@nokia.com > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > xcon@ietf.org > > Sent: 06/01/2004 18:50 > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > > Hi Roni, > >=20 > > > My opinion is that the conference policy needs only a=20 > > > conference duration parameter if any.=20 > > > I think that reservation is an external=20 > > > application to the focus. According to the conference=20 > > > framework the focus is using the information in the=20 > > > conference policy server and the focus is=20 > > > not the right place for reservation. > >=20 > > The reservation is sent to CPS, not to focus. > > I think it makes sense to have this (repeat time) capability=20 > > in protocol > > since we need the feature anyway in real-world (either in CPCP > > or in some new mystery protocol between the user and the reservation > > application). > >=20 > >=20 > >=20 > > -- > > Petri > >=20 > >=20 > > > Regards > > > Roni Even > > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, December 15, 2003 4:57 PM > > To: xcon@ietf.org > > Subject: [XCON] CPCP Requirement: Repeat times > >=20 > >=20 > > A conference has start and stop times. Although the current proposed > > solution has repeat times (eg: meeting repeats weekly), there is no > > requirement for such. > >=20 > > Do we see a need for such capability using CPCP? If so, then=20 > > we need to add > > a requirement. >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 20 11:05:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08131 for ; Tue, 20 Jan 2004 11:05:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN2-00053w-7r for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KG4qfD019454 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:04:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyN2-00053f-2u for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:04:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08039 for ; Tue, 20 Jan 2004 11:04:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyMz-0001Pf-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:04:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyMA-0001KT-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiyLD-0001DN-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyLF-0004nK-TR; Tue, 20 Jan 2004 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiyKr-0004m0-Su for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:02:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07769 for ; Tue, 20 Jan 2004 11:02:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiyKp-0001B7-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:02:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyJr-000170-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:36 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AiyJU-000137-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:01:13 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18441; Tue, 20 Jan 2004 11:03:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Tue, 20 Jan 2004 11:00:39 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A05E@zoe.office.snowshore.com> Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Thread-Index: AcPJH4/jcdtJO/pxQ2yUxNSRsZcu8wV164Qg From: "Eric Burger" To: "Even, Roni" , 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does this mean that the bridge needs to be able to support every layout = *and* every mixing algorithm, on a stream-by-stream basis? > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, December 23, 2003 1:35 AM > To: 'Umesh.Chandra@nokia.com'; Even, Roni; xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 > Hi, > The participant will need to select first the layout ( 3 sub=20 > windows in your > example) and then select who will be seen in the windows by=20 > defining the > mix. The media policy control protocol should allow this. > Roni Even >=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: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] > Sent: Tuesday, December 23, 2003 1:40 AM > To: roni.even@polycom.co.il; xcon@ietf.org > Subject: RE: [XCON] I-D=20 > ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 >=20 > Hello Roni, >=20 > Thanks for your input..So basically the user can decide the=20 > contents of the > screen layout, but the screen layout can be static or can be changed > dynamically based on user selection. In nutshell can the end=20 > user say i > want to see user A, B, C in mosaic ( assuming the conferencing server > supports this kind of layout) to the conferencing server?.=20 > Each user can > send its own request for content and for layout. In that case=20 > the mixer has > to support the functionality to select the desired layout and=20 > select the > particular streams the end user is asking for. >=20 > And in case the conferencing server doesnt support this kind=20 > of layout, what > is the protocol to inform the client..I dont know if this=20 > would fall under > media control policy..=20 >=20 >=20 > BR=20 > Umesh > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Monday, December 22, 2003 1:19 AM > To: Chandra Umesh (NRC/Dallas); xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 > Umesh, > The video mixing scenarios describe typical video=20 > conferencing scenarios. An > participants with the right privilege level may select the=20 > screen layout he > wants to have. The selection may be for his own view or for the whole > conference view. The availability of such functionality per=20 > participant or > per conference is dependent on the mixer functionality. This=20 > functionality > is not saying what is the content (whose video is mixed) but=20 > on the layout. > Layout may be static during the conference or may be changed=20 > dynamically > based on user selection (e.g. start with a single view and=20 > request a quad > view later) or the layout can change automatically based on=20 > the number of > participants in the conference. > The selection of the layout is independent from the selection of which > stream is seen in each sub-window >=20 > Roni Even > =20 >=20 > ************************************* > Roni Even >=20 > Polycom Israel >=20 > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >=20 >=20 > -----Original Message----- > From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] > Sent: Thursday, December 18, 2003 11:06 PM > To: xcon@ietf.org > Subject: RE: [XCON] I-D=20 > ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 > Hello, >=20 > In section 4.1 of the draft ( Video mixing scenarios ), it=20 > says " For video > the user selects one of a set of pre-defined video=20 > presentations offered by > the server". Does it mean that end user in the conference=20 > knows what all > streams the server can offer? Does this pre-defined video list changes > dynamically ?...For example Particpant A is getting video of=20 > particpant B, > but decides to watch a mosaic of participant B and C, it=20 > should be able to > do so...The server should be able to mix the streams of B and=20 > C and send one > stream to A... >=20 > Umesh > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Thursday, December 18, 2003 2:29 PM > Cc: xcon@ietf.org > Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Centralized Conferencing=20 > Working Group of > the IETF. >=20 > Title : Conferencing Scenarios > Author(s) : R. Even > Filename : draft-ietf-xcon-conference-scenarios-00.txt > Pages : 15 > Date : 2003-12-18 > =09 > This document describes SIP conferencing scenarios. It will describe > basic and advance conferencing scenarios. These conferencing > scenarios will help with definition and evaluation of the > requirements for SIP conferencing framework and the protocol > associated with the framework. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference -scenarios-00. txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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-conference-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-conference-scenarios-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ 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 Jan 20 11:32:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10160 for ; Tue, 20 Jan 2004 11:32:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiymt-0006lr-Cn for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:31:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KGVZfY026021 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:31:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiymt-0006lc-80 for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10136 for ; Tue, 20 Jan 2004 11:31:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiyms-0003WD-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiylx-0003RN-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:30:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiylR-0003NW-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiylP-0006ZB-QI; Tue, 20 Jan 2004 11:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyky-0006Vv-Bc for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:29:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09849 for ; Tue, 20 Jan 2004 11:29:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiykx-0003Ly-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:29:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyk2-0003IU-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:28:39 -0500 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 1Aiyjj-0003Eh-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:28:20 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 18:27:47 +0200 Message-ID: From: "Even, Roni" To: "'Eric Burger'" , "Even, Roni" , xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Tue, 20 Jan 2004 18:27:39 +0200 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=none autolearn=no version=2.60 Eric, The bridge needs to support only the layouts it can. As for mixing it is always by assigning a stream to a sub-window explicitly or implicitly Roni Even -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Tuesday, January 20, 2004 6:01 PM To: Even, Roni; xcon@ietf.org Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Does this mean that the bridge needs to be able to support every layout *and* every mixing algorithm, on a stream-by-stream basis? > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, December 23, 2003 1:35 AM > To: 'Umesh.Chandra@nokia.com'; Even, Roni; xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > > > Hi, > The participant will need to select first the layout ( 3 sub > windows in your > example) and then select who will be seen in the windows by > defining the > mix. The media policy control protocol should allow this. > Roni Even > > ************************************* > Roni Even > VP Product Planning > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] > Sent: Tuesday, December 23, 2003 1:40 AM > To: roni.even@polycom.co.il; xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > > > > Hello Roni, > > Thanks for your input..So basically the user can decide the > contents of the > screen layout, but the screen layout can be static or can be changed > dynamically based on user selection. In nutshell can the end > user say i > want to see user A, B, C in mosaic ( assuming the conferencing server > supports this kind of layout) to the conferencing server?. > Each user can > send its own request for content and for layout. In that case > the mixer has > to support the functionality to select the desired layout and > select the > particular streams the end user is asking for. > > And in case the conferencing server doesnt support this kind > of layout, what > is the protocol to inform the client..I dont know if this > would fall under > media control policy.. > > > BR > Umesh > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Monday, December 22, 2003 1:19 AM > To: Chandra Umesh (NRC/Dallas); xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > > > Umesh, > The video mixing scenarios describe typical video > conferencing scenarios. An > participants with the right privilege level may select the > screen layout he > wants to have. The selection may be for his own view or for the whole > conference view. The availability of such functionality per > participant or > per conference is dependent on the mixer functionality. This > functionality > is not saying what is the content (whose video is mixed) but > on the layout. > Layout may be static during the conference or may be changed > dynamically > based on user selection (e.g. start with a single view and > request a quad > view later) or the layout can change automatically based on > the number of > participants in the conference. > The selection of the layout is independent from the selection of which > stream is seen in each sub-window > > Roni Even > > > ************************************* > Roni Even > > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] > Sent: Thursday, December 18, 2003 11:06 PM > To: xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > > > Hello, > > In section 4.1 of the draft ( Video mixing scenarios ), it > says " For video > the user selects one of a set of pre-defined video > presentations offered by > the server". Does it mean that end user in the conference > knows what all > streams the server can offer? Does this pre-defined video list changes > dynamically ?...For example Particpant A is getting video of > particpant B, > but decides to watch a mosaic of participant B and C, it > should be able to > do so...The server should be able to mix the streams of B and > C and send one > stream to A... > > Umesh > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Thursday, December 18, 2003 2:29 PM > Cc: xcon@ietf.org > Subject: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt > > > 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 : Conferencing Scenarios > Author(s) : R. Even > Filename : draft-ietf-xcon-conference-scenarios-00.txt > Pages : 15 > Date : 2003-12-18 > > This document describes SIP conferencing scenarios. It will describe > basic and advance conferencing scenarios. These conferencing > scenarios will help with definition and evaluation of the > requirements for SIP conferencing framework and the protocol > associated with the framework. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference -scenarios-00. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-conference-scenarios-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-conference-scenarios-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. _______________________________________________ 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 Jan 20 11:32:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10177 for ; Tue, 20 Jan 2004 11:32:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiymu-0006ma-2g for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:31:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KGVakB026066 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiymt-0006mL-Th for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10140 for ; Tue, 20 Jan 2004 11:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiyms-0003WI-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiylz-0003RV-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:30:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiylR-0003NY-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiylP-0006Z3-Fy; Tue, 20 Jan 2004 11:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiykx-0006Vq-9n for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:29:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09820 for ; Tue, 20 Jan 2004 11:29:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiykw-0003Lq-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:29:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyjz-0003IE-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:28:37 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1Aiyjc-0003Ed-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:28:12 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18428; Tue, 20 Jan 2004 11:30:14 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [XCON] CPCP Requirement: de-activating a conference Date: Tue, 20 Jan 2004 11:27:41 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB24226@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: de-activating a conference Thread-Index: AcPavp5btxftZ1twSOCZmE/iKvpdLQENpX7Q From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I *very* much agree with Roni here. I would argue that CPCP should have = small primitives that applications can build arbitrarily complex = behaviors. Let us not try to put everything in CPCP. As Roni has said in a few = messages, reservation processing is extremely complex. There is no = reason to put all of this into CPCP. Just starting and ending a = conference is enough. All of the complex behaviors that people have = been discussing can be built on this. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Wednesday, January 14, 2004 10:14 AM > To: 'Michael Hammer'; Even, Roni > Cc: 'Drage, Keith (Keith)'; 'Rosen, Brian'; Even, Roni; > 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Mike, > This is a service that is not available by all conference=20 > bridges and will > need to be implemented by an application server that will use=20 > CPCP to start > the breakout session and invite the participants to it.=20 > What happens in the end of the breakout session, does the=20 > conference bridge > bring all to the main conference, can the moderator extend=20 > it,, all these > are applications and not part of the conference service in my view > Roni >=20 >=20 >=20 >=20 > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, January 14, 2004 5:02 PM > To: Even, Roni > Cc: 'Drage, Keith (Keith)'; 'Rosen, Brian'; Even, Roni; > 'hisham.khartabil@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: de-activating a conference >=20 >=20 > Roni, >=20 > I am still a little fuzzy on what is/is not being addressed. >=20 > For example, if the conference moderator wanted to create=20 > breakout sessions=20 > with defined start and stop times with assigned participants,=20 > could this be=20 > setup with CPCP such that the breakouts are created in 10=20 > minutes, then=20 > terminate after another 10 minutes? Note, for certain=20 > purposes, one may=20 > want to disallow independent sidebars using that conference server. >=20 > Is this possible? >=20 > Mike >=20 >=20 > At 10:18 AM 1/14/2004 +0200, Even, Roni wrote: > >Hi, > > > >I did not think that the conference work was also addressing=20 > reservation > >systems and that is why it is not clear to me why we need=20 > the start and > stop > >time of a conference in CPCP. If conference reservation is=20 > in the scope of > >the work then we need some more parameters in CPCP for=20 > supporting it. We > >also need to understand what it may support for example can=20 > I give a start > >time in 2050, what about next month, can I learn from CPCP=20 > what resources > >are available at a specific time. If the start and stop=20 > time are only what > >they sound and the application is handled by an application=20 > server then > what > >is the difference between having a start and stop time and=20 > letting the > >application server start the conference when the scheduled=20 > time has arrived > >Thanks > >Roni Even > > > >************************************* > >Roni Even > > > >Polycom Israel > > > >Tel: +972-3-9251200 > >Cell: +972-55-481099 > >email:roni.even@polycom.co.il > >******************************************* > > > > > >-----Original Message----- > >From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >Sent: Tuesday, January 13, 2004 6:55 PM > >To: 'Rosen, Brian'; 'Even, Roni' > >Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > >Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > >I do not remember seeing the existence of this separate=20 > protocol in any of > >the conferencing documents so far (either in SIPPING or=20 > XCON). (If I am > >wrong then pointers gratefully received). If it exists, then=20 > I think we > >should clearly identify what its scope is, if only to aid=20 > the discussion of > >what the other protocols may or may not do. > > > >We clearly need a start and stop time for conferencing. At=20 > the moment the > >only protocol it can be in is the CPCP. If we are going to=20 > have an informed > >discussion about why it is not in CPCP we need to understand=20 > clearly what > >the alternative protocol is. > > > >regards > > > >Keith > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 06 January 2004 14:14 > > > To: 'Even, Roni' > > > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > I don't like this idea because I think that we need a > > > standardized interface > > > for scheduling and "external application server" sounds very > > > proprietary to > > > me. I guess I could be convinced we need a separate=20 > interface, with a > > > separate protocol (maybe it could be iCal), but I'm not=20 > yet convinced > > > just specifying a start time in the future isn't a sufficient > > > reservation > > > mechanism. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: Tuesday, January 06, 2004 7:22 AM > > > To: 'Rosen, Brian'; 'hisham.khartabil@nokia.com'; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > Brian, > > > My suggestion is not to have reservation in the=20 > conference policy. The > > > conference policy is used by the focus according to the > > > conference framework > > > and the focus is not the place for handling reservation.=20 > I think that > > > reservation is handled by an external application server that > > > will start the > > > conference using CPCP at the time when the conference > > > scheduled time has > > > arrived. The focus may use the conference duration > > > information in order to > > > notify the participants that it the conference end-time=20 > is coming and > > > terminate the conference. Extension of the should be done > > > using CPCP either > > > by the participant or an application server. > > > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Monday, December 15, 2003 4:25 PM > > > To: 'hisham.khartabil@nokia.com'; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > Again, I'm worried about "privileged users". I think we need > > > to finish > > > some discussions we started a while ago that essentially are > > > semantics. > > > What is an "inactivated" conference, and how does it differ from a > > > conference that can be re-instantiated (a weekly meeting=20 > for example)? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 7:57 AM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: de-activating a conference > > > > > > > > > This is in reference to requirement REQ-B9 in > > > = http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-B9: It MUST be possible to inactive a conference for = defined > > > period of time. > > > > > > There are start and stop times for a conference. A conference > > > might live for days, weeks or even months. Should a > > > conference policy, using CPCP, allow a privileged user to > > > de-activate a conference for a period of time within the > > > start and stop times of a conference? Examples are > > > administrator is performing some maintenance. > > > > > > Regards, > > > Hisham > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 20 11:39:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11209 for ; Tue, 20 Jan 2004 11:39:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyts-0007qZ-6F for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:38:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KGcmMV030157 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 11:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyts-0007qK-0e for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:38:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11187 for ; Tue, 20 Jan 2004 11:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiytr-0004dk-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyt7-0004Y0-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:38:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AiysD-0004Qb-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:37:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AiysD-0004jg-4Q for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 11:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiysA-0007QA-0v; Tue, 20 Jan 2004 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyrd-0007My-2a for xcon@optimus.ietf.org; Tue, 20 Jan 2004 11:36:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10932 for ; Tue, 20 Jan 2004 11:36:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiyrc-0004KG-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:36:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyqe-0004CJ-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:35:29 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1Aiypf-0003vY-00 for xcon@ietf.org; Tue, 20 Jan 2004 11:34:27 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 8803; Tue, 20 Jan 2004 11:36:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Date: Tue, 20 Jan 2004 11:33:57 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB2422A@zoe.office.snowshore.com> Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-conference-scenarios-00.txt Thread-Index: AcPfcllzfRj2ZsIbRrSnrSf9rQJlrQAAMmKA From: "Eric Burger" To: "Even, Roni" , 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable That means the protocol has to have "I can't do that" or negotiation = messages. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, January 20, 2004 11:28 AM > To: Eric Burger; Even, Roni; xcon@ietf.org > Subject: RE: [XCON] I-D > ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 > Eric, > The bridge needs to support only the layouts it can. As for=20 > mixing it is > always by assigning a stream to a sub-window explicitly or implicitly > Roni Even >=20 >=20 >=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, January 20, 2004 6:01 PM > To: Even, Roni; xcon@ietf.org > Subject: RE: [XCON] I-D=20 > ACTION:draft-ietf-xcon-conference-scenarios-00.txt >=20 >=20 > Does this mean that the bridge needs to be able to support=20 > every layout > *and* every mixing algorithm, on a stream-by-stream basis? >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tuesday, December 23, 2003 1:35 AM > > To: 'Umesh.Chandra@nokia.com'; Even, Roni; xcon@ietf.org > > Subject: RE: [XCON] I-D > > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > >=20 > >=20 > > Hi, > > The participant will need to select first the layout ( 3 sub=20 > > windows in your > > example) and then select who will be seen in the windows by=20 > > defining the > > mix. The media policy control protocol should allow this. > > Roni Even > >=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: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] > > Sent: Tuesday, December 23, 2003 1:40 AM > > To: roni.even@polycom.co.il; xcon@ietf.org > > Subject: RE: [XCON] I-D=20 > > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > >=20 > >=20 > >=20 > > Hello Roni, > >=20 > > Thanks for your input..So basically the user can decide the=20 > > contents of the > > screen layout, but the screen layout can be static or can be changed > > dynamically based on user selection. In nutshell can the end=20 > > user say i > > want to see user A, B, C in mosaic ( assuming the=20 > conferencing server > > supports this kind of layout) to the conferencing server?.=20 > > Each user can > > send its own request for content and for layout. In that case=20 > > the mixer has > > to support the functionality to select the desired layout and=20 > > select the > > particular streams the end user is asking for. > >=20 > > And in case the conferencing server doesnt support this kind=20 > > of layout, what > > is the protocol to inform the client..I dont know if this=20 > > would fall under > > media control policy..=20 > >=20 > >=20 > > BR=20 > > Umesh > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Monday, December 22, 2003 1:19 AM > > To: Chandra Umesh (NRC/Dallas); xcon@ietf.org > > Subject: RE: [XCON] I-D > > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > >=20 > >=20 > > Umesh, > > The video mixing scenarios describe typical video=20 > > conferencing scenarios. An > > participants with the right privilege level may select the=20 > > screen layout he > > wants to have. The selection may be for his own view or for=20 > the whole > > conference view. The availability of such functionality per=20 > > participant or > > per conference is dependent on the mixer functionality. This=20 > > functionality > > is not saying what is the content (whose video is mixed) but=20 > > on the layout. > > Layout may be static during the conference or may be changed=20 > > dynamically > > based on user selection (e.g. start with a single view and=20 > > request a quad > > view later) or the layout can change automatically based on=20 > > the number of > > participants in the conference. > > The selection of the layout is independent from the=20 > selection of which > > stream is seen in each sub-window > >=20 > > Roni Even > > =20 > >=20 > > ************************************* > > Roni Even > >=20 > > Polycom Israel > >=20 > > Tel: +972-3-9251200 > > Cell: +972-55-481099 > > email:roni.even@polycom.co.il > > ******************************************* > >=20 > >=20 > > -----Original Message----- > > From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] > > Sent: Thursday, December 18, 2003 11:06 PM > > To: xcon@ietf.org > > Subject: RE: [XCON] I-D=20 > > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > >=20 > >=20 > > Hello, > >=20 > > In section 4.1 of the draft ( Video mixing scenarios ), it=20 > > says " For video > > the user selects one of a set of pre-defined video=20 > > presentations offered by > > the server". Does it mean that end user in the conference=20 > > knows what all > > streams the server can offer? Does this pre-defined video=20 > list changes > > dynamically ?...For example Particpant A is getting video of=20 > > particpant B, > > but decides to watch a mosaic of participant B and C, it=20 > > should be able to > > do so...The server should be able to mix the streams of B and=20 > > C and send one > > stream to A... > >=20 > > Umesh > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Internet-Drafts@ietf.org > > Sent: Thursday, December 18, 2003 2:29 PM > > Cc: xcon@ietf.org > > Subject: [XCON] I-D=20 > ACTION:draft-ietf-xcon-conference-scenarios-00.txt > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Centralized Conferencing=20 > > Working Group of > > the IETF. > >=20 > > Title : Conferencing Scenarios > > Author(s) : R. Even > > Filename : draft-ietf-xcon-conference-scenarios-00.txt > > Pages : 15 > > Date : 2003-12-18 > > =09 > > This document describes SIP conferencing scenarios. It=20 > will describe > > basic and advance conferencing scenarios. These conferencing > > scenarios will help with definition and evaluation of the > > requirements for SIP conferencing framework and the protocol > > associated with the framework. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference > -scenarios-00. > txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > 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-conference-scenarios-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-xcon-conference-scenarios-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 20 15:46:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21010 for ; Tue, 20 Jan 2004 15:46:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2kj-0008U1-Qb for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 15:45:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KKjbA2032601 for xcon-archive@odin.ietf.org; Tue, 20 Jan 2004 15:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2kj-0008Tk-KF for xcon-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 15:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20950 for ; Tue, 20 Jan 2004 15:45:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj2ki-0000ZT-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 15:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj2jn-0000VJ-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 15:44:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj2jG-0000SQ-00 for xcon-web-archive@ietf.org; Tue, 20 Jan 2004 15:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jF-000802-2j; Tue, 20 Jan 2004 15:44:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2in-0007ym-7f for xcon@optimus.ietf.org; Tue, 20 Jan 2004 15:43:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20508; Tue, 20 Jan 2004 15:43:34 -0500 (EST) Message-Id: <200401202043.PAA20508@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: xcon@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 20 Jan 2004 15:43:34 -0500 Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-01.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.4 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 Filename : draft-ietf-xcon-cpcp-reqs-01.txt Pages : 18 Date : 2004-1-20 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-01.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-01.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-1-20142529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-cpcp-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142529.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 08:22:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19458 for ; Wed, 21 Jan 2004 08:22:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIIg-0000KU-SN for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:21:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LDLgBm001262 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIIg-0000KH-Nx for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 08:21:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19436 for ; Wed, 21 Jan 2004 08:21:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIIa-00046P-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:21:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIF5-0003r3-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:18:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjIBY-0003ZX-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:14:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIBF-0008JO-KG; Wed, 21 Jan 2004 08:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIB5-0008J2-9U for xcon@optimus.ietf.org; Wed, 21 Jan 2004 08:13:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19153 for ; Wed, 21 Jan 2004 08:13:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIAz-0003Xn-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:13:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjI6N-0003Hq-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:09:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjI4z-00038n-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:07:33 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LD7MY12403 for ; Wed, 21 Jan 2004 15:07:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 15:07:19 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 15:07:19 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Wed, 21 Jan 2004 15:07:18 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017975F9@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPGIWcIlTiXGJmISm6SBXk6+COhvwY1RK8AAEoo77A= To: , X-OriginalArrivalTime: 21 Jan 2004 13:07:19.0220 (UTC) FILETIME=[7FF9EF40:01C3E01F] 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 We thought of that just before releasing the new requirements draft. We = concluded that hidden user policy can be local implementation since the = moderator of the conference who sets the policy and decides who is = hidden and not could be the terrorist himself. Therefore we concluded = that hidden users must be allowed by network administrators for any = conference and must not result is a modification to the conference = policy. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: 20.January.2004 18:01 > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > Would Legal Intercept be in or out? E.g., hidden=20 > participants that CANNOT be known. >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Friday, December 19, 2003 6:14 AM > > To: hisham.khartabil@nokia.com; mhammer@cisco.com > > Cc: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >=20 > >=20 > > I believe hidden users are appropriate. > >=20 > > I do not believe that this adds complexity to the=20 > > specifications (particularly to the specification of CPCP),=20 > > so I see no need to make it a DEFER as far as the=20 > > specifications are concerned. It may add complexity to the=20 > > implementation, so I am quite happy to see it a MAY in the=20 > > requirements, so that it is optional to implement. > >=20 > > As regards the legal implications of hidden users, then yes,=20 > > there may be priveleged users that are able to request the=20 > > identity of hidden users (along with an indication that they=20 > > are hidden). This of course requires the enabling of such a=20 > > privileged user in the first place. > >=20 > > Secondly, it may not be necessary to identify hidden users,=20 > > but merely that there are hidden users in the conference (in=20 > > addition to any that may have made themselves visible). Some=20 > > countries require some form of tone or announcement on voice=20 > > conferences when someone else is listening in. They also=20 > > require an announcement or other indication in the call is=20 > > being recorded. > >=20 > > regards > >=20 > > Keith > >=20 > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > >=20 > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: 15 December 2003 16:29 > > > To: mhammer@cisco.com > > > Cc: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: ext Michael Hammer [mailto:mhammer@cisco.com] > > > > Sent: 15.December.2003 18:17 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > > > Cc: xcon@ietf.org > > > > Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > > >=20 > > > >=20 > > > > Related to this is there a requirement that, while not=20 > > > revealing the=20 > > > > identity of a hidden user, the conference policy contains=20 > > > > state indication=20 > > > > about either the presence of hidden users, or the=20 > > > > possibility/preclusion=20 > > > > that such hidden users may be present? > > > >=20 > > > > I am anticipating that: > > > > 1) Laws may exist that require notification of such. > > >=20 > > > That's a good point. This might require changes to the=20 > > > conference event package to indicate if there are hidden=20 > > > participants or not, and if so, how many. > > >=20 > > > The question remain: is there a need for such a feature (to=20 > > > hide users?)? > > >=20 > > > Regards, > > > Hisham > > >=20 > > > > 2) In some conferences, participants may want technical=20 > > > > assurance that=20 > > > > hidden users are not possible before they speak. > > > >=20 > > > > Mike > > > >=20 > > > >=20 > > > > At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > > > >This is in reference to requirements REQ-A7 and REQ-E10 in=20 > > > >=20 > >=20 >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-A7: It SHOULD be possible to participate in a=20 > conference as a > > > hidden user. Hidden user is present in a conference, but=20 > > his presence > > > is not revealed. > > > > > > REQ-E10: It MUST be possible to allow and disallow=20 > > hidden membership > > > in a conference. > > > > > >Should a conference policy, using CPCP, specify if a user=20 > > can be hidden?=20 > > >This means that the conference state package does not report the=20 > > >participation on the hidden user. CPCP is used to identify=20 > > which users are=20 > > >hidden. The list of hidden users is only manipulated by a=20 > > privileged user=20 > > >such as the moderator. > > > > > >Regards, > > >Hisham > > > > > >_______________________________________________ > > >XCON mailing list > > >XCON@ietf.org > > >https://www1.ietf.org/mailman/listinfo/xcon > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 08:27:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19657 for ; Wed, 21 Jan 2004 08:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjINb-0000db-5R for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:26:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LDQlJ5002445 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:26:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjINb-0000dM-0b for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 08:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19639 for ; Wed, 21 Jan 2004 08:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjINU-0004MT-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:26:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIJ1-0004AD-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:22:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjIGF-0003vF-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIG5-00008W-Iw; Wed, 21 Jan 2004 08:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIFA-00007E-OG for xcon@optimus.ietf.org; Wed, 21 Jan 2004 08:18:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19290 for ; Wed, 21 Jan 2004 08:18:03 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIF4-0003qb-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:17:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIBS-0003bz-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:14:16 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AjI7k-0003L2-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:10:24 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LD9vV19759 for ; Wed, 21 Jan 2004 15:09:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 15:09:57 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 15:09:55 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 21 Jan 2004 15:09:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017975FA@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPVBUoCgM0ehvpfSxOikskifw/TkwJ8ajmwAEorNEA= To: , , , X-OriginalArrivalTime: 21 Jan 2004 13:09:55.0993 (UTC) FILETIME=[DD6B9890:01C3E01F] 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 Yes. We all have weekly meetings with predefined start and stop times. I = think it is a valid use case for a user to create a conference policy to = satisfy this once and once only. Regards, Hisham > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: 20.January.2004 18:01 > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > Koskelainen Petri > (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > For that matter, is there a use case for end points (XCON)=20 > doing such complicated scheduling? Why don't we just take=20 > the bridge out of service? >=20 > Wow! Agreeing with Roni twice in one day!!! >=20 >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Wednesday, January 07, 2004 4:56 AM > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > petri.koskelainen@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Hisham, > >=20 > > The conference server is not mentioned in > > draft-ietf-sipping-conferencing-framework-01. The framework=20 > > mentioned the > > conference policy server. As for reservation my view is that=20 > > reservation is > > starting an ad-hoc conference when the schedule time has=20 > > arrived and it > > should not be part of the conference policy. Reservation is=20 > a separate > > application from the conference policy. I suggest that if=20 > you want to > > address it then we should have a separate element in the=20 > > frame work which > > will be a reservation server. > >=20 > > Roni > >=20 > > ************************************* > > Roni Even > >=20 > > Polycom Israel > >=20 > > Tel: +972-3-9251200 > > Cell: +972-55-481099 > > email:roni.even@polycom.co.il > > ******************************************* > >=20 > >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, January 07, 2004 11:22 AM > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > No, the focus host (conference server) is the one that handles the > > reservations. The focus is only created and destroyed by the=20 > > conference > > server according to the start and stop times. > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: 06.January.2004 19:06 > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > Khartabil Hisham > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hi Petri, > > > The CPS is a data storage that is used by the focus, so the=20 > > > focus will have > > > to handle the reservation > > > Roni > > >=20 > > > -----Original Message----- > > > From: petri.koskelainen@nokia.com > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > > xcon@ietf.org > > > Sent: 06/01/2004 18:50 > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > > Hi Roni, > > >=20 > > > > My opinion is that the conference policy needs only a=20 > > > > conference duration parameter if any.=20 > > > > I think that reservation is an external=20 > > > > application to the focus. According to the conference=20 > > > > framework the focus is using the information in the=20 > > > > conference policy server and the focus is=20 > > > > not the right place for reservation. > > >=20 > > > The reservation is sent to CPS, not to focus. > > > I think it makes sense to have this (repeat time) capability=20 > > > in protocol > > > since we need the feature anyway in real-world (either in CPCP > > > or in some new mystery protocol between the user and the=20 > reservation > > > application). > > >=20 > > >=20 > > >=20 > > > -- > > > Petri > > >=20 > > >=20 > > > > Regards > > > > Roni Even > > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, December 15, 2003 4:57 PM > > > To: xcon@ietf.org > > > Subject: [XCON] CPCP Requirement: Repeat times > > >=20 > > >=20 > > > A conference has start and stop times. Although the=20 > current proposed > > > solution has repeat times (eg: meeting repeats weekly),=20 > there is no > > > requirement for such. > > >=20 > > > Do we see a need for such capability using CPCP? If so, then=20 > > > we need to add > > > a requirement. > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 08:32:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19822 for ; Wed, 21 Jan 2004 08:32:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjISC-0000vV-23 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:31:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LDVW5d003555 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:31:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjISB-0000vG-Tx for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 08:31:31 -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 IAA19802 for ; Wed, 21 Jan 2004 08:31:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIS5-0004ac-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:31:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIOc-0004S2-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:27:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjILD-0004Fs-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIKu-0000Xr-8y; Wed, 21 Jan 2004 08:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIKT-0000X4-3H for xcon@optimus.ietf.org; Wed, 21 Jan 2004 08:23:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19517 for ; Wed, 21 Jan 2004 08:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIKM-0004EQ-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:23:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIHm-00041d-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:20:47 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AjIDU-0003iB-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:16:20 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18426; Wed, 21 Jan 2004 08:18:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 21 Jan 2004 08:15:20 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB2423A@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPVBUoCgM0ehvpfSxOikskifw/TkwJ8ajmwAEorNEAAADW4AA== From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable So the use case isn't "I'm taking the bridge out of service for = maintenance", but "I have a weekly meeting, except for next week." That would be better handled by a calendaring application (i.e., why it = doesn't belong in XCON). > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, January 21, 2004 8:10 AM > To: Eric Burger; roni.even@polycom.co.il; petri.koskelainen@nokia.com; > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Yes. >=20 > We all have weekly meetings with predefined start and stop=20 > times. I think it is a valid use case for a user to create a=20 > conference policy to satisfy this once and once only. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > Sent: 20.January.2004 18:01 > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > Koskelainen Petri > > (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > For that matter, is there a use case for end points (XCON)=20 > > doing such complicated scheduling? Why don't we just take=20 > > the bridge out of service? > >=20 > > Wow! Agreeing with Roni twice in one day!!! > >=20 > >=20 > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hisham, > > >=20 > > > The conference server is not mentioned in > > > draft-ietf-sipping-conferencing-framework-01. The framework=20 > > > mentioned the > > > conference policy server. As for reservation my view is that=20 > > > reservation is > > > starting an ad-hoc conference when the schedule time has=20 > > > arrived and it > > > should not be part of the conference policy. Reservation is=20 > > a separate > > > application from the conference policy. I suggest that if=20 > > you want to > > > address it then we should have a separate element in the=20 > > > frame work which > > > will be a reservation server. > > >=20 > > > Roni > > >=20 > > > ************************************* > > > Roni Even > > >=20 > > > Polycom Israel > > >=20 > > > Tel: +972-3-9251200 > > > Cell: +972-55-481099 > > > email:roni.even@polycom.co.il > > > ******************************************* > > >=20 > > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > No, the focus host (conference server) is the one that handles the > > > reservations. The focus is only created and destroyed by the=20 > > > conference > > > server according to the start and stop times. > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: 06.January.2004 19:06 > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > > Khartabil Hisham > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > Hi Petri, > > > > The CPS is a data storage that is used by the focus, so the=20 > > > > focus will have > > > > to handle the reservation > > > > Roni > > > >=20 > > > > -----Original Message----- > > > > From: petri.koskelainen@nokia.com > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > > > xcon@ietf.org > > > > Sent: 06/01/2004 18:50 > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > > Hi Roni, > > > >=20 > > > > > My opinion is that the conference policy needs only a=20 > > > > > conference duration parameter if any.=20 > > > > > I think that reservation is an external=20 > > > > > application to the focus. According to the conference=20 > > > > > framework the focus is using the information in the=20 > > > > > conference policy server and the focus is=20 > > > > > not the right place for reservation. > > > >=20 > > > > The reservation is sent to CPS, not to focus. > > > > I think it makes sense to have this (repeat time) capability=20 > > > > in protocol > > > > since we need the feature anyway in real-world (either in CPCP > > > > or in some new mystery protocol between the user and the=20 > > reservation > > > > application). > > > >=20 > > > >=20 > > > >=20 > > > > -- > > > > Petri > > > >=20 > > > >=20 > > > > > Regards > > > > > Roni Even > > > > >=20 > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > To: xcon@ietf.org > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > >=20 > > > >=20 > > > > A conference has start and stop times. Although the=20 > > current proposed > > > > solution has repeat times (eg: meeting repeats weekly),=20 > > there is no > > > > requirement for such. > > > >=20 > > > > Do we see a need for such capability using CPCP? If so, then=20 > > > > we need to add > > > > a requirement. > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 08:36:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19976 for ; Wed, 21 Jan 2004 08:36:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIWy-0001BB-TX for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:36:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LDaSSd004527 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIWy-0001Aw-Pg for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 08:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19961 for ; Wed, 21 Jan 2004 08:36:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIWs-0004nz-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjITh-0004hM-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjIS1-0004a9-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:31:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIRi-0000t3-4w; Wed, 21 Jan 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIRP-0000rx-Va for xcon@optimus.ietf.org; Wed, 21 Jan 2004 08:30:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19764 for ; Wed, 21 Jan 2004 08:30:42 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIRJ-0004YB-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIOF-0004QO-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:27:29 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjIKU-0004Ea-00; Wed, 21 Jan 2004 08:23:34 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LDNIY06276; Wed, 21 Jan 2004 15:23:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 15:23:18 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 15:23:17 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-01.txt Date: Wed, 21 Jan 2004 15:23:17 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B17C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-01.txt Thread-Index: AcPflkbM/UzVkjxCRDaN710qxEIAEwAieJ+A To: Cc: X-OriginalArrivalTime: 21 Jan 2004 13:23:17.0757 (UTC) FILETIME=[BB4F12D0:01C3E021] 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 Let me elaborate of the changes that we made to the requirements draft: - floor control aligned with floor control requirements document We added a few new requirements for floor control policy (note, not = floor control protocol) - removed the concept of hidden user As Eric pre-emptively pointed out :) We concluded that hidden user policy can be local implementation since = the moderator of the conference who sets the policy and decides who is = hidden and not could be the terrorist himself. Therefore we concluded = that hidden users must be allowed by network administrators for any = conference and must not result is a modification to the conference = policy. Of course those hidden users must be authenticated and authorised by the = network. - anonymous membership modified Clarified that support is only for participants that are properly = authenticated but appear as anonymous to other users. - removed "inactive" We concluded that an administrator requiring to suspend a conference for = maintenance reasons can do so by modifying the start time of the = conference. It is an implementation issue whether the administrator = caches the current participants and invites them back to the conference = once it starts again, or requires the participants to invite themselves = back in (if on the dial-in list). - added media type requirement (e.g. audio, video) It was apparent that a conference creator needs to indicate to the = conference server what media types to INVITE uses into the conference = with. Some requirements were added to enable the conference creator to = set the policy for that. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Internet-Drafts@ietf.org > Sent: 20.January.2004 22:44 > Cc: xcon@ietf.org > Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Centralized Conferencing=20 > Working Group of the IETF. >=20 > Title : Requirements for Conference Policy=20 > Control Protocol > Author(s) : P. Koskelainen > Filename : draft-ietf-xcon-cpcp-reqs-01.txt > Pages : 18 > Date : 2004-1-20 > =09 > 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-01.txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > 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-01.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-01.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 08:38:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20149 for ; Wed, 21 Jan 2004 08:38:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIYR-0001W3-Ak for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:37:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LDbxk6005821 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:37:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIYQ-0001Vo-V6 for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 08:37:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20054 for ; Wed, 21 Jan 2004 08:37:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIYP-0004u6-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:37:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIWt-0004oU-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:36:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjITv-0004g3-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjITc-0000zZ-Ec; Wed, 21 Jan 2004 08:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIT3-0000wK-MH for xcon@optimus.ietf.org; Wed, 21 Jan 2004 08:32:25 -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 IAA19846 for ; Wed, 21 Jan 2004 08:32:23 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjISx-0004dJ-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:32:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIOq-0004U7-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:28:05 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjIN8-0004Lg-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:26:18 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LDQ7Y09911 for ; Wed, 21 Jan 2004 15:26:07 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 15:26:07 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 15:26:06 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 21 Jan 2004 15:26:06 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017975FC@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPVBUoCgM0ehvpfSxOikskifw/TkwJ8ajmwAEorNEAAADW4AAAAVlwQ To: , X-OriginalArrivalTime: 21 Jan 2004 13:26:06.0357 (UTC) FILETIME=[1FCD6450:01C3E022] 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 There is no need to blow up a simple requirement of start, stop and = repeat times which can easily be handled in CPCP to be the size of = calendering that requires a separate protocol that needs to be somehow = linked to the corresponding conference policy. /Hisham > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: 21.January.2004 15:15 > To: Khartabil Hisham (Nokia-TP/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > So the use case isn't "I'm taking the bridge out of service=20 > for maintenance", but "I have a weekly meeting, except for next week." >=20 > That would be better handled by a calendaring application=20 > (i.e., why it doesn't belong in XCON). >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, January 21, 2004 8:10 AM > > To: Eric Burger; roni.even@polycom.co.il;=20 > petri.koskelainen@nokia.com; > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Yes. > >=20 > > We all have weekly meetings with predefined start and stop=20 > > times. I think it is a valid use case for a user to create a=20 > > conference policy to satisfy this once and once only. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > Sent: 20.January.2004 18:01 > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > Koskelainen Petri > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > For that matter, is there a use case for end points (XCON)=20 > > > doing such complicated scheduling? Why don't we just take=20 > > > the bridge out of service? > > >=20 > > > Wow! Agreeing with Roni twice in one day!!! > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > Hisham, > > > >=20 > > > > The conference server is not mentioned in > > > > draft-ietf-sipping-conferencing-framework-01. The framework=20 > > > > mentioned the > > > > conference policy server. As for reservation my view is that=20 > > > > reservation is > > > > starting an ad-hoc conference when the schedule time has=20 > > > > arrived and it > > > > should not be part of the conference policy. Reservation is=20 > > > a separate > > > > application from the conference policy. I suggest that if=20 > > > you want to > > > > address it then we should have a separate element in the=20 > > > > frame work which > > > > will be a reservation server. > > > >=20 > > > > Roni > > > >=20 > > > > ************************************* > > > > Roni Even > > > >=20 > > > > Polycom Israel > > > >=20 > > > > Tel: +972-3-9251200 > > > > Cell: +972-55-481099 > > > > email:roni.even@polycom.co.il > > > > ******************************************* > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > > xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > No, the focus host (conference server) is the one that=20 > handles the > > > > reservations. The focus is only created and destroyed by the=20 > > > > conference > > > > server according to the start and stop times. > > > >=20 > > > > /Hisham > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > Sent: 06.January.2004 19:06 > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > > > Khartabil Hisham > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > Hi Petri, > > > > > The CPS is a data storage that is used by the focus, so the=20 > > > > > focus will have > > > > > to handle the reservation > > > > > Roni > > > > >=20 > > > > > -----Original Message----- > > > > > From: petri.koskelainen@nokia.com > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > > > > xcon@ietf.org > > > > > Sent: 06/01/2004 18:50 > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > > Hi Roni, > > > > >=20 > > > > > > My opinion is that the conference policy needs only a=20 > > > > > > conference duration parameter if any.=20 > > > > > > I think that reservation is an external=20 > > > > > > application to the focus. According to the conference=20 > > > > > > framework the focus is using the information in the=20 > > > > > > conference policy server and the focus is=20 > > > > > > not the right place for reservation. > > > > >=20 > > > > > The reservation is sent to CPS, not to focus. > > > > > I think it makes sense to have this (repeat time) capability=20 > > > > > in protocol > > > > > since we need the feature anyway in real-world (either in CPCP > > > > > or in some new mystery protocol between the user and the=20 > > > reservation > > > > > application). > > > > >=20 > > > > >=20 > > > > >=20 > > > > > -- > > > > > Petri > > > > >=20 > > > > >=20 > > > > > > Regards > > > > > > Roni Even > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > To: xcon@ietf.org > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > >=20 > > > > >=20 > > > > > A conference has start and stop times. Although the=20 > > > current proposed > > > > > solution has repeat times (eg: meeting repeats weekly),=20 > > > there is no > > > > > requirement for such. > > > > >=20 > > > > > Do we see a need for such capability using CPCP? If so, then=20 > > > > > we need to add > > > > > a requirement. > > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 08:52:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20781 for ; Wed, 21 Jan 2004 08:52:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIm9-0002kN-MA for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:52:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LDq9Hp010553 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 08:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIm9-0002k8-Hm for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 08:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20778 for ; Wed, 21 Jan 2004 08:52:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIm8-0005pQ-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIlC-0005na-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:51:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjIl3-0005lL-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 08:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIl3-0002eZ-F1; Wed, 21 Jan 2004 08:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjIkB-0002dV-OI for xcon@optimus.ietf.org; Wed, 21 Jan 2004 08:50: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 IAA20687 for ; Wed, 21 Jan 2004 08:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjIkA-0005jy-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjIjG-0005hP-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:49:11 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AjIiX-0005f8-00 for xcon@ietf.org; Wed, 21 Jan 2004 08:48:26 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LDmJBF010366; Wed, 21 Jan 2004 08:48:24 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i0LDkHc23420; Wed, 21 Jan 2004 08:47:48 -0500 Message-ID: <400E8299.8090604@cs.columbia.edu> Date: Wed, 21 Jan 2004 08:46:01 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: eburger@snowshore.com, xcon@ietf.org Subject: Re: [XCON] CPCP Requirement: Repeat times References: <2038BCC78B1AD641891A0D1AE133DBB7017975FC@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017975FC@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > There is no need to blow up a simple requirement of start, stop and > repeat times which can easily be handled in CPCP to be the size of > calendering that requires a separate protocol that needs to be > somehow linked to the corresponding conference policy. As soon as you have repeat times, you run into the problem that people expect to be able to export real calsch-like repeat times ("every other Monday, except if it is Dec. 25"), not just the basic subset. We had the same discussion for CPL and ended up with calsch, rather than trying to do 20% or 50% of it. > > /Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 09:44:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23967 for ; Wed, 21 Jan 2004 09:44:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJaS-00077b-Ln for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 09:44:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LEi8v9027369 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 09:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJaS-00077M-GX for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 09:44:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23930 for ; Wed, 21 Jan 2004 09:44:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJaQ-0001pA-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:44:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJZY-0001mL-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:43:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AjJYV-0001j6-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:42:07 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AjJYS-0006g3-Vs for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJYQ-0006t8-DV; Wed, 21 Jan 2004 09:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJY7-0006sb-Ub for xcon@optimus.ietf.org; Wed, 21 Jan 2004 09:41:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23861 for ; Wed, 21 Jan 2004 09:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJY6-0001ht-00 for xcon@ietf.org; Wed, 21 Jan 2004 09:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJXI-0001ZZ-00 for xcon@ietf.org; Wed, 21 Jan 2004 09:40:53 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AjJVs-0001GJ-00 for xcon@ietf.org; Wed, 21 Jan 2004 09:39:24 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23301 for ; Wed, 21 Jan 2004 09:38:48 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19981 for ; Wed, 21 Jan 2004 09:38:44 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jan 2004 09:38:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B62FB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'xcon@ietf.org'" Subject: FW: [XCON] CPCP Requirement: Repeat times Date: Wed, 21 Jan 2004 09:38:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I did a reply instead of reply all :( Brian -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Wednesday, January 21, 2004 9:37 AM To: Brian.Rosen@marconi.com Subject: RE: [XCON] CPCP Requirement: Repeat times Brian, I'm not sure if your reply was supposed to be to the list or just personal. Anyway, some response inline... > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 21.January.2004 16:09 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > I think we need to figure out where we are going on scheduling. > > First, let me say that I think we SHOULD allow CPCP to at > least specify > start/stop > times for conferences, and that if the start time is in the > future, that is > a reservation. Agreed. > > What I want to discuss is, how far do we go, and what is the end game? > I think we can agree that generalized scheduling is complex, > and standards > exist (iCal). So, the issue I want to discuss is: > if we allow simple scheduling (start/stop) now, do we EVENTUALLY > allow complex scheduling? That implies duplicating > significant > parts of e.g. iCal. > > We could consider an alternative - explicitly support an iCal > (actually > iMIP) transaction now. > > One could allow the iMIP Request/Reply only (ie subset of > iMIP) now (or > maybe as a minimum). > > Or we could pull in some or all of calsch If there is an XML schema already defined that we can use, then it is possible to embed that in CPCP. If you look at the solution we are proposing (using XCAP), each feature, like conference-time, has its own XML namespace. We can take the iCal XML namespace and just drop it in there. Regards, Hisham > > Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, January 21, 2004 8:10 AM > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > petri.koskelainen@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Yes. > > > > We all have weekly meetings with predefined start and stop > > times. I think it is a valid use case for a user to create a > > conference policy to satisfy this once and once only. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > Sent: 20.January.2004 18:01 > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > Koskelainen Petri > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > For that matter, is there a use case for end points (XCON) > > > doing such complicated scheduling? Why don't we just take > > > the bridge out of service? > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > -----Original Message----- > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Hisham, > > > > > > > > The conference server is not mentioned in > > > > draft-ietf-sipping-conferencing-framework-01. The framework > > > > mentioned the > > > > conference policy server. As for reservation my view is that > > > > reservation is > > > > starting an ad-hoc conference when the schedule time has > > > > arrived and it > > > > should not be part of the conference policy. Reservation is > > > a separate > > > > application from the conference policy. I suggest that if > > > you want to > > > > address it then we should have a separate element in the > > > > frame work which > > > > will be a reservation server. > > > > > > > > Roni > > > > > > > > ************************************* > > > > Roni Even > > > > > > > > Polycom Israel > > > > > > > > Tel: +972-3-9251200 > > > > Cell: +972-55-481099 > > > > email:roni.even@polycom.co.il > > > > ******************************************* > > > > > > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > > > xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > No, the focus host (conference server) is the one that > handles the > > > > reservations. The focus is only created and destroyed by the > > > > conference > > > > server according to the start and stop times. > > > > > > > > /Hisham > > > > > > > > > -----Original Message----- > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > Sent: 06.January.2004 19:06 > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; > > > > > Khartabil Hisham > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > Hi Petri, > > > > > The CPS is a data storage that is used by the focus, so the > > > > > focus will have > > > > > to handle the reservation > > > > > Roni > > > > > > > > > > -----Original Message----- > > > > > From: petri.koskelainen@nokia.com > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; > > > > xcon@ietf.org > > > > > Sent: 06/01/2004 18:50 > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > Hi Roni, > > > > > > > > > > > My opinion is that the conference policy needs only a > > > > > > conference duration parameter if any. > > > > > > I think that reservation is an external > > > > > > application to the focus. According to the conference > > > > > > framework the focus is using the information in the > > > > > > conference policy server and the focus is > > > > > > not the right place for reservation. > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > I think it makes sense to have this (repeat time) capability > > > > > in protocol > > > > > since we need the feature anyway in real-world (either in CPCP > > > > > or in some new mystery protocol between the user and the > > > reservation > > > > > application). > > > > > > > > > > > > > > > > > > > > -- > > > > > Petri > > > > > > > > > > > > > > > > Regards > > > > > > Roni Even > > > > > > > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > To: xcon@ietf.org > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > A conference has start and stop times. Although the > > > current proposed > > > > > solution has repeat times (eg: meeting repeats weekly), > > > there is no > > > > > requirement for such. > > > > > > > > > > Do we see a need for such capability using CPCP? If so, then > > > > > we need to add > > > > > a requirement. > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 21 09:55:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24265 for ; Wed, 21 Jan 2004 09:55:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJlA-0007j7-Ut for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 09:55:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LEtCSR029697 for xcon-archive@odin.ietf.org; Wed, 21 Jan 2004 09:55:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJlA-0007iu-Lq for xcon-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 09:55:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24248 for ; Wed, 21 Jan 2004 09:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJl8-0002Gk-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJkG-0002EP-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:54:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjJjz-0002CS-00 for xcon-web-archive@ietf.org; Wed, 21 Jan 2004 09:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJk0-0007dA-VC; Wed, 21 Jan 2004 09:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJjB-0007Zl-6k for xcon@optimus.ietf.org; Wed, 21 Jan 2004 09:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24208 for ; Wed, 21 Jan 2004 09:53:06 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJj9-0002BU-00 for xcon@ietf.org; Wed, 21 Jan 2004 09:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJiF-00029z-00 for xcon@ietf.org; Wed, 21 Jan 2004 09:52:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjJhY-00028B-00 for xcon@ietf.org; Wed, 21 Jan 2004 09:51:28 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0LEpRY09834 for ; Wed, 21 Jan 2004 16:51:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 16:51:21 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 16:51:20 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 16:51:21 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 21 Jan 2004 16:51:20 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797600@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPgJUIkyw/nNeU1Q++SEbyJtLJp8gACD7zA To: Cc: , X-OriginalArrivalTime: 21 Jan 2004 14:51:21.0548 (UTC) FILETIME=[08B198C0:01C3E02E] 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 Great, we can do what you did for CPL, or even rip off what you have for = CPL. Just to point out that the currently proposed solution has, here is an = example: 2003-06-16T10:00:00Z 2003-09-16T12:00:00Z http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xcap-cpcp-usag= e-01.txt if you want to read details. I think it is very similar to what you have in CPL, but we can unify the = syntax. /Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 21.January.2004 15:46 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Cc: eburger@snowshore.com; xcon@ietf.org > Subject: Re: [XCON] CPCP Requirement: Repeat times >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > There is no need to blow up a simple requirement of start, stop and > > repeat times which can easily be handled in CPCP to be the size of > > calendering that requires a separate protocol that needs to be > > somehow linked to the corresponding conference policy. >=20 >=20 > As soon as you have repeat times, you run into the problem=20 > that people=20 > expect to be able to export real calsch-like repeat times=20 > ("every other=20 > Monday, except if it is Dec. 25"), not just the basic subset.=20 > We had the=20 > same discussion for CPL and ended up with calsch, rather than=20 > trying to=20 > do 20% or 50% of it. >=20 > >=20 > > /Hisham >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Jan 25 08:35:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03308 for ; Sun, 25 Jan 2004 08:35:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkPv-0001oV-8l for xcon-archive@odin.ietf.org; Sun, 25 Jan 2004 08:35:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PDZBJM006967 for xcon-archive@odin.ietf.org; Sun, 25 Jan 2004 08:35:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkPv-0001oI-3i for xcon-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 08:35: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 IAA03305 for ; Sun, 25 Jan 2004 08:35:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkkPt-0005mN-00 for xcon-web-archive@ietf.org; Sun, 25 Jan 2004 08:35:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkkOw-0005lA-00 for xcon-web-archive@ietf.org; Sun, 25 Jan 2004 08:34:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkkOn-0005jk-00 for xcon-web-archive@ietf.org; Sun, 25 Jan 2004 08:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkOn-0001kl-0m; Sun, 25 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkO4-0001k9-Am for xcon@optimus.ietf.org; Sun, 25 Jan 2004 08:33:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03268 for ; Sun, 25 Jan 2004 08:33:14 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkkO3-0005jU-00 for xcon@ietf.org; Sun, 25 Jan 2004 08:33:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkkN8-0005hN-00 for xcon@ietf.org; Sun, 25 Jan 2004 08:32:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AkkMF-0005eS-00 for xcon@ietf.org; Sun, 25 Jan 2004 08:31:23 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0PDVLV22260 for ; Sun, 25 Jan 2004 15:31:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 25 Jan 2004 15:31:21 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 25 Jan 2004 15:31:21 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 25 Jan 2004 15:31:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Sun, 25 Jan 2004 15:31:20 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0C8C@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPgLQbpnjy9QPWtRP+sDgYL/r5lmACXqZ4w To: X-OriginalArrivalTime: 25 Jan 2004 13:31:20.0840 (UTC) FILETIME=[84E6B080:01C3E347] 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Back to the original question in this thread: > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > If so, then we need to add a requirement. I guess we can close this open issue now as rough consensus seems to=20 be that such a requirement is needed (at least for the start/stop/repeat = times). Note that we don't have to design the actual solution yet=20 (e.g. using iCal vs defining own format). -- Petri > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 21.January.2004 16:09 > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > I think we need to figure out where we are going on scheduling. > >=20 > > First, let me say that I think we SHOULD allow CPCP to at=20 > > least specify start/stop times for conferences, and that if=20 > > the start time is in the future, that is a reservation. >=20 > Agreed. >=20 > >=20 > > What I want to discuss is, how far do we go, and what is=20 > the end game? > > I think we can agree that generalized scheduling is complex,=20 > > and standards exist (iCal). So, the issue I want to discuss is: > > if we allow simple scheduling (start/stop) now, do we EVENTUALLY > > allow complex scheduling? That implies duplicating significant > > parts of e.g. iCal. > >=20 > > We could consider an alternative - explicitly support an iCal=20 > > (actually iMIP) transaction now. =20 > >=20 > > One could allow the iMIP Request/Reply only (ie subset of=20 > > iMIP) now (or maybe as a minimum). =20 > >=20 > > Or we could pull in some or all of calsch >=20 > If there is an XML schema already defined that we can use, then it is > possible to embed that in CPCP. If you look at the solution=20 > we are proposing (using XCAP), each feature, like conference-time, has = its own=20 > XML namespace. > We can take the iCal XML namespace and just drop it in there. >=20 > Regards, > Hisham >=20 > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Yes. > > >=20 > > > We all have weekly meetings with predefined start and stop=20 > > > times. I think it is a valid use case for a user to create a=20 > > > conference policy to satisfy this once and once only. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > > -----Original Message----- > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > Sent: 20.January.2004 18:01 > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > Koskelainen Petri > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > For that matter, is there a use case for end points (XCON)=20 > > > > doing such complicated scheduling? Why don't we just take=20 > > > > the bridge out of service? > > > >=20 > > > > Wow! Agreeing with Roni twice in one day!!! > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > Hisham, > > > > >=20 > > > > > The conference server is not mentioned in > > > > > draft-ietf-sipping-conferencing-framework-01. The framework=20 > > > > > mentioned the > > > > > conference policy server. As for reservation my view is that=20 > > > > > reservation is > > > > > starting an ad-hoc conference when the schedule time has=20 > > > > > arrived and it > > > > > should not be part of the conference policy. Reservation is=20 > > > > a separate > > > > > application from the conference policy. I suggest that if=20 > > > > you want to > > > > > address it then we should have a separate element in the=20 > > > > > frame work which > > > > > will be a reservation server. > > > > >=20 > > > > > Roni > > > > >=20 > > > > > ************************************* > > > > > Roni Even > > > > >=20 > > > > > Polycom Israel > > > > >=20 > > > > > Tel: +972-3-9251200 > > > > > Cell: +972-55-481099 > > > > > email:roni.even@polycom.co.il > > > > > ******************************************* > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com=20 > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > > > xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > No, the focus host (conference server) is the one that=20 > > handles the > > > > > reservations. The focus is only created and destroyed by the=20 > > > > > conference > > > > > server according to the start and stop times. > > > > >=20 > > > > > /Hisham > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: 06.January.2004 19:06 > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > > > > Khartabil Hisham > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Hi Petri, > > > > > > The CPS is a data storage that is used by the focus, so the=20 > > > > > > focus will have > > > > > > to handle the reservation > > > > > > Roni > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: petri.koskelainen@nokia.com > > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > > > > > xcon@ietf.org > > > > > > Sent: 06/01/2004 18:50 > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > > Hi Roni, > > > > > >=20 > > > > > > > My opinion is that the conference policy needs only a=20 > > > > > > > conference duration parameter if any.=20 > > > > > > > I think that reservation is an external=20 > > > > > > > application to the focus. According to the conference=20 > > > > > > > framework the focus is using the information in the=20 > > > > > > > conference policy server and the focus is=20 > > > > > > > not the right place for reservation. > > > > > >=20 > > > > > > The reservation is sent to CPS, not to focus. > > > > > > I think it makes sense to have this (repeat time)=20 > capability in protocol since we need the feature anyway in real-world=20 > (either in CPCP or in some new mystery protocol between the user and = the=20 > > > > reservation application). > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > -- > > > > > > Petri > > > > > >=20 > > > > > >=20 > > > > > > > Regards > > > > > > > Roni Even > > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > To: xcon@ietf.org > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > >=20 > > > > > >=20 > > > > > > A conference has start and stop times. Although the=20 > > > > current proposed solution has repeat times (eg: meeting repeats = weekly),=20 > > > > there is no requirement for such. > > > > > >=20 > > > > > > Do we see a need for such capability using CPCP? If=20 > so, then we need to add a requirement. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sun Jan 25 08:48:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03750 for ; Sun, 25 Jan 2004 08:48:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkcZ-0002fb-0D for xcon-archive@odin.ietf.org; Sun, 25 Jan 2004 08:48:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PDmEGj010257 for xcon-archive@odin.ietf.org; Sun, 25 Jan 2004 08:48:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkcY-0002fK-R1 for xcon-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 08:48:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03744 for ; Sun, 25 Jan 2004 08:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkkcX-0006Ry-00 for xcon-web-archive@ietf.org; Sun, 25 Jan 2004 08:48:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akkbc-0006Q2-00 for xcon-web-archive@ietf.org; Sun, 25 Jan 2004 08:47:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkkbL-0006No-00 for xcon-web-archive@ietf.org; Sun, 25 Jan 2004 08:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkkbM-0002YW-DM; Sun, 25 Jan 2004 08:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akkaa-0002XX-Rl for xcon@optimus.ietf.org; Sun, 25 Jan 2004 08:46:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03689 for ; Sun, 25 Jan 2004 08:46:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkkaZ-0006Ma-00 for xcon@ietf.org; Sun, 25 Jan 2004 08:46:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkkZd-0006Kn-00 for xcon@ietf.org; Sun, 25 Jan 2004 08:45:14 -0500 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 1AkkYs-0006Gu-00 for xcon@ietf.org; Sun, 25 Jan 2004 08:44:27 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Jan 2004 15:43:54 +0200 Message-ID: From: "Even, Roni" To: "'petri.koskelainen@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Sun, 25 Jan 2004 15:43:53 +0200 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=none autolearn=no version=2.60 Hi, Repeating myself I would like to state my objection, and I would suggest to have conference reservation functionality not in the scope of conference policy but maybe as an application functionality that we may consider as a different working item. Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: petri.koskelainen@nokia.com [mailto:petri.koskelainen@nokia.com] Sent: Sunday, January 25, 2004 3:31 PM To: xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Back to the original question in this thread: > > > > > > Do we see a need for such capability using CPCP? > > > > > > If so, then we need to add a requirement. I guess we can close this open issue now as rough consensus seems to be that such a requirement is needed (at least for the start/stop/repeat times). Note that we don't have to design the actual solution yet (e.g. using iCal vs defining own format). -- Petri > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 21.January.2004 16:09 > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > I think we need to figure out where we are going on scheduling. > > > > First, let me say that I think we SHOULD allow CPCP to at > > least specify start/stop times for conferences, and that if > > the start time is in the future, that is a reservation. > > Agreed. > > > > > What I want to discuss is, how far do we go, and what is > the end game? > > I think we can agree that generalized scheduling is complex, > > and standards exist (iCal). So, the issue I want to discuss is: > > if we allow simple scheduling (start/stop) now, do we EVENTUALLY > > allow complex scheduling? That implies duplicating significant > > parts of e.g. iCal. > > > > We could consider an alternative - explicitly support an iCal > > (actually iMIP) transaction now. > > > > One could allow the iMIP Request/Reply only (ie subset of > > iMIP) now (or maybe as a minimum). > > > > Or we could pull in some or all of calsch > > If there is an XML schema already defined that we can use, then it is > possible to embed that in CPCP. If you look at the solution > we are proposing (using XCAP), each feature, like conference-time, has its own > XML namespace. > We can take the iCal XML namespace and just drop it in there. > > Regards, > Hisham > > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Yes. > > > > > > We all have weekly meetings with predefined start and stop > > > times. I think it is a valid use case for a user to create a > > > conference policy to satisfy this once and once only. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > Sent: 20.January.2004 18:01 > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > Koskelainen Petri > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > For that matter, is there a use case for end points (XCON) > > > > doing such complicated scheduling? Why don't we just take > > > > the bridge out of service? > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > -----Original Message----- > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > The conference server is not mentioned in > > > > > draft-ietf-sipping-conferencing-framework-01. The framework > > > > > mentioned the > > > > > conference policy server. As for reservation my view is that > > > > > reservation is > > > > > starting an ad-hoc conference when the schedule time has > > > > > arrived and it > > > > > should not be part of the conference policy. Reservation is > > > > a separate > > > > > application from the conference policy. I suggest that if > > > > you want to > > > > > address it then we should have a separate element in the > > > > > frame work which > > > > > will be a reservation server. > > > > > > > > > > Roni > > > > > > > > > > ************************************* > > > > > Roni Even > > > > > > > > > > Polycom Israel > > > > > > > > > > Tel: +972-3-9251200 > > > > > Cell: +972-55-481099 > > > > > email:roni.even@polycom.co.il > > > > > ******************************************* > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > > > > xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > No, the focus host (conference server) is the one that > > handles the > > > > > reservations. The focus is only created and destroyed by the > > > > > conference > > > > > server according to the start and stop times. > > > > > > > > > > /Hisham > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: 06.January.2004 19:06 > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; > > > > > > Khartabil Hisham > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > The CPS is a data storage that is used by the focus, so the > > > > > > focus will have > > > > > > to handle the reservation > > > > > > Roni > > > > > > > > > > > > -----Original Message----- > > > > > > From: petri.koskelainen@nokia.com > > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; > > > > > xcon@ietf.org > > > > > > Sent: 06/01/2004 18:50 > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > My opinion is that the conference policy needs only a > > > > > > > conference duration parameter if any. > > > > > > > I think that reservation is an external > > > > > > > application to the focus. According to the conference > > > > > > > framework the focus is using the information in the > > > > > > > conference policy server and the focus is > > > > > > > not the right place for reservation. > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > I think it makes sense to have this (repeat time) > capability in protocol since we need the feature anyway in real-world > (either in CPCP or in some new mystery protocol between the user and the > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Petri > > > > > > > > > > > > > > > > > > > Regards > > > > > > > Roni Even > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > To: xcon@ietf.org > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > A conference has start and stop times. Although the > > > > current proposed solution has repeat times (eg: meeting repeats weekly), > > > > there is no requirement for such. > > > > > > > > > > > > Do we see a need for such capability using CPCP? If > so, then we need to add a requirement. _______________________________________________ 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 Jan 26 20:24:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28613 for ; Mon, 26 Jan 2004 20:24:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHwz-0003VY-MQ for xcon-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1NXdH013474 for xcon-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHwy-0003V9-OE for xcon-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:23:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28385 for ; Mon, 26 Jan 2004 20:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHww-0002Pc-00 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:23:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHrQ-00013u-00 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:17:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlHq2-0000uf-00 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:16:22 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlHh0-0007fs-D8 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20: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 1AlHcp-0001QZ-Kh; Mon, 26 Jan 2004 20:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al68k-0000mG-31 for xcon@optimus.ietf.org; Mon, 26 Jan 2004 07:46:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04643 for ; Mon, 26 Jan 2004 07:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al68j-0004Ye-00 for xcon@ietf.org; Mon, 26 Jan 2004 07:46:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al67l-0004Wo-00 for xcon@ietf.org; Mon, 26 Jan 2004 07:45:54 -0500 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 1Al675-0004R0-00 for xcon@ietf.org; Mon, 26 Jan 2004 07:45:11 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jan 2004 14:44:34 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , "Even, Roni" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 26 Jan 2004 14:44:33 +0200 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=none autolearn=no version=2.60 Hisham, I can not understand why you conclude that there is a rough consensus. I looked at this thread and there are mixed views. I would like to add that considering another protocol like iCal points again to show that this is a different application. I can agree to conference duration but I would recommend not to get into future reservations 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Monday, January 26, 2004 1:43 PM To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Roni, Your objection is noted, but I believe we have rough consensus on this issue already. The most recent discussions on the list have already tapped into the solution domain. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Even, Roni > Sent: 25.January.2004 15:44 > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Hi, > Repeating myself I would like to state my objection, and I > would suggest to > have conference reservation functionality not in the scope of > conference > policy but maybe as an application functionality that we may > consider as a > different working item. > Roni > > ************************************* > Roni Even > > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* > > > -----Original Message----- > From: petri.koskelainen@nokia.com [mailto:petri.koskelainen@nokia.com] > Sent: Sunday, January 25, 2004 3:31 PM > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > Back to the original question in this thread: > > > > > > > > Do we see a need for such capability using CPCP? > > > > > > > If so, then we need to add a requirement. > > I guess we can close this open issue now as rough consensus seems to > be that such a requirement is needed (at least for the > start/stop/repeat > times). > Note that we don't have to design the actual solution yet > (e.g. using iCal vs defining own format). > > -- > Petri > > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 21.January.2004 16:09 > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > I think we need to figure out where we are going on scheduling. > > > > > > First, let me say that I think we SHOULD allow CPCP to at > > > least specify start/stop times for conferences, and that if > > > the start time is in the future, that is a reservation. > > > > Agreed. > > > > > > > > What I want to discuss is, how far do we go, and what is > > the end game? > > > I think we can agree that generalized scheduling is complex, > > > and standards exist (iCal). So, the issue I want to discuss is: > > > if we allow simple scheduling (start/stop) now, do we EVENTUALLY > > > allow complex scheduling? That implies duplicating > significant > > > parts of e.g. iCal. > > > > > > We could consider an alternative - explicitly support an iCal > > > (actually iMIP) transaction now. > > > > > > One could allow the iMIP Request/Reply only (ie subset of > > > iMIP) now (or maybe as a minimum). > > > > > > Or we could pull in some or all of calsch > > > > If there is an XML schema already defined that we can use, > then it is > > possible to embed that in CPCP. If you look at the solution > > we are proposing (using XCAP), each feature, like > conference-time, has its > own > > XML namespace. > > We can take the iCal XML namespace and just drop it in there. > > > > Regards, > > Hisham > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Yes. > > > > > > > > We all have weekly meetings with predefined start and stop > > > > times. I think it is a valid use case for a user to create a > > > > conference policy to satisfy this once and once only. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > -----Original Message----- > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > Sent: 20.January.2004 18:01 > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > > Koskelainen Petri > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > For that matter, is there a use case for end points (XCON) > > > > > doing such complicated scheduling? Why don't we just take > > > > > the bridge out of service? > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > The conference server is not mentioned in > > > > > > draft-ietf-sipping-conferencing-framework-01. The framework > > > > > > mentioned the > > > > > > conference policy server. As for reservation my > view is that > > > > > > reservation is > > > > > > starting an ad-hoc conference when the schedule time has > > > > > > arrived and it > > > > > > should not be part of the conference policy. Reservation is > > > > > a separate > > > > > > application from the conference policy. I suggest that if > > > > > you want to > > > > > > address it then we should have a separate element in the > > > > > > frame work which > > > > > > will be a reservation server. > > > > > > > > > > > > Roni > > > > > > > > > > > > ************************************* > > > > > > Roni Even > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > Cell: +972-55-481099 > > > > > > email:roni.even@polycom.co.il > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > > > > > xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the one that > > > handles the > > > > > > reservations. The focus is only created and > destroyed by the > > > > > > conference > > > > > > server according to the start and stop times. > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; > > > > > > > Khartabil Hisham > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > The CPS is a data storage that is used by the > focus, so the > > > > > > > focus will have > > > > > > > to handle the reservation > > > > > > > Roni > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com; > > > > > > xcon@ietf.org > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > My opinion is that the conference policy needs only a > > > > > > > > conference duration parameter if any. > > > > > > > > I think that reservation is an external > > > > > > > > application to the focus. According to the conference > > > > > > > > framework the focus is using the information in the > > > > > > > > conference policy server and the focus is > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > I think it makes sense to have this (repeat time) > > capability in protocol since we need the feature anyway in > real-world > > (either in CPCP or in some new mystery protocol between the > user and the > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > Roni Even > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > To: xcon@ietf.org > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. Although the > > > > > current proposed solution has repeat times (eg: > meeting repeats > weekly), > > > > > there is no requirement for such. > > > > > > > > > > > > > > Do we see a need for such capability using CPCP? If > > so, then we need to add a requirement. > > _______________________________________________ > 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 Jan 26 20:24:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28670 for ; Mon, 26 Jan 2004 20:24:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHx4-0003Wf-Pr for xcon-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1Ncsa013546 for xcon-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHx4-0003WP-JQ for xcon-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:23:38 -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 UAA28427 for ; Mon, 26 Jan 2004 20:23:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHx2-0002RX-00 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:23:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHra-00015l-00 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:17:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlHq4-0000sb-02 for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:16:24 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlHgf-0007cv-Vf for xcon-web-archive@ietf.org; Mon, 26 Jan 2004 20:06:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHcb-0001HO-Ud; Mon, 26 Jan 2004 20:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al59n-0004zH-LI for xcon@optimus.ietf.org; Mon, 26 Jan 2004 06:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03280 for ; Mon, 26 Jan 2004 06:43:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al59j-0001wL-00 for xcon@ietf.org; Mon, 26 Jan 2004 06:43:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al58m-0001ue-00 for xcon@ietf.org; Mon, 26 Jan 2004 06:42:53 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Al58a-0001sw-00 for xcon@ietf.org; Mon, 26 Jan 2004 06:42:40 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QBgZV27214 for ; Mon, 26 Jan 2004 13:42:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 13:42:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 13:42:33 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 26 Jan 2004 13:42:33 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179763B@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPjSbqbUyTy5KfuQ8S31/dftNSEWAAt4UFA To: , , X-OriginalArrivalTime: 26 Jan 2004 11:42:33.0563 (UTC) FILETIME=[7CC102B0:01C3E401] 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 Roni, Your objection is noted, but I believe we have rough consensus on this = issue already. The most recent discussions on the list have already = tapped into the solution domain. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Even, Roni > Sent: 25.January.2004 15:44 > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hi, > Repeating myself I would like to state my objection, and I=20 > would suggest to > have conference reservation functionality not in the scope of=20 > conference > policy but maybe as an application functionality that we may=20 > consider as a > different working item. > Roni >=20 > ************************************* > Roni Even >=20 > 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: Sunday, January 25, 2004 3:31 PM > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 >=20 > Back to the original question in this thread: >=20 > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > If so, then we need to add a requirement. >=20 > I guess we can close this open issue now as rough consensus seems to=20 > be that such a requirement is needed (at least for the=20 > start/stop/repeat > times). > Note that we don't have to design the actual solution yet=20 > (e.g. using iCal vs defining own format). >=20 > -- > Petri >=20 > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 21.January.2004 16:09 > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > I think we need to figure out where we are going on scheduling. > > >=20 > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > least specify start/stop times for conferences, and that if=20 > > > the start time is in the future, that is a reservation. > >=20 > > Agreed. > >=20 > > >=20 > > > What I want to discuss is, how far do we go, and what is=20 > > the end game? > > > I think we can agree that generalized scheduling is complex,=20 > > > and standards exist (iCal). So, the issue I want to discuss is: > > > if we allow simple scheduling (start/stop) now, do we EVENTUALLY > > > allow complex scheduling? That implies duplicating > significant > > > parts of e.g. iCal. > > >=20 > > > We could consider an alternative - explicitly support an iCal=20 > > > (actually iMIP) transaction now. =20 > > >=20 > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > iMIP) now (or maybe as a minimum). =20 > > >=20 > > > Or we could pull in some or all of calsch > >=20 > > If there is an XML schema already defined that we can use,=20 > then it is > > possible to embed that in CPCP. If you look at the solution=20 > > we are proposing (using XCAP), each feature, like=20 > conference-time, has its > own=20 > > XML namespace. > > We can take the iCal XML namespace and just drop it in there. > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > > Brian > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > Yes. > > > >=20 > > > > We all have weekly meetings with predefined start and stop=20 > > > > times. I think it is a valid use case for a user to create a=20 > > > > conference policy to satisfy this once and once only. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > Sent: 20.January.2004 18:01 > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > Koskelainen Petri > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > For that matter, is there a use case for end points (XCON)=20 > > > > > doing such complicated scheduling? Why don't we just take=20 > > > > > the bridge out of service? > > > > >=20 > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Hisham, > > > > > >=20 > > > > > > The conference server is not mentioned in > > > > > > draft-ietf-sipping-conferencing-framework-01. The framework=20 > > > > > > mentioned the > > > > > > conference policy server. As for reservation my=20 > view is that=20 > > > > > > reservation is > > > > > > starting an ad-hoc conference when the schedule time has=20 > > > > > > arrived and it > > > > > > should not be part of the conference policy. Reservation is=20 > > > > > a separate > > > > > > application from the conference policy. I suggest that if=20 > > > > > you want to > > > > > > address it then we should have a separate element in the=20 > > > > > > frame work which > > > > > > will be a reservation server. > > > > > >=20 > > > > > > Roni > > > > > >=20 > > > > > > ************************************* > > > > > > Roni Even > > > > > >=20 > > > > > > Polycom Israel > > > > > >=20 > > > > > > Tel: +972-3-9251200 > > > > > > Cell: +972-55-481099 > > > > > > email:roni.even@polycom.co.il > > > > > > ******************************************* > > > > > >=20 > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > > > > xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > No, the focus host (conference server) is the one that=20 > > > handles the > > > > > > reservations. The focus is only created and=20 > destroyed by the=20 > > > > > > conference > > > > > > server according to the start and stop times. > > > > > >=20 > > > > > > /Hisham > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > > > > > Khartabil Hisham > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi Petri, > > > > > > > The CPS is a data storage that is used by the=20 > focus, so the=20 > > > > > > > focus will have > > > > > > > to handle the reservation > > > > > > > Roni > > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > > > > > > xcon@ietf.org > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > > Hi Roni, > > > > > > >=20 > > > > > > > > My opinion is that the conference policy needs only a=20 > > > > > > > > conference duration parameter if any.=20 > > > > > > > > I think that reservation is an external=20 > > > > > > > > application to the focus. According to the conference=20 > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > conference policy server and the focus is=20 > > > > > > > > not the right place for reservation. > > > > > > >=20 > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > I think it makes sense to have this (repeat time)=20 > > capability in protocol since we need the feature anyway in=20 > real-world=20 > > (either in CPCP or in some new mystery protocol between the=20 > user and the=20 > > > > > reservation application). > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > -- > > > > > > > Petri > > > > > > >=20 > > > > > > >=20 > > > > > > > > Regards > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > To: xcon@ietf.org > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > >=20 > > > > > > >=20 > > > > > > > A conference has start and stop times. Although the=20 > > > > > current proposed solution has repeat times (eg:=20 > meeting repeats > weekly),=20 > > > > > there is no requirement for such. > > > > > > >=20 > > > > > > > Do we see a need for such capability using CPCP? If=20 > > so, then we need to add a requirement. >=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 Tue Jan 27 09:11:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05593 for ; Tue, 27 Jan 2004 09:11:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTvR-0001TA-JO for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 09:10:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0REAjQl005642 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 09:10:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTvR-0001Sv-E5 for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:10:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05572 for ; Tue, 27 Jan 2004 09:10:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTvP-0003mv-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 09:10:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTuT-0003kN-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 09:09:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTtk-0003hx-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 09:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTtl-0001L4-2v; Tue, 27 Jan 2004 09:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTtT-0001KG-J7 for xcon@optimus.ietf.org; Tue, 27 Jan 2004 09:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05511 for ; Tue, 27 Jan 2004 09:08:40 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTtS-0003h0-00 for xcon@ietf.org; Tue, 27 Jan 2004 09:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTsU-0003eP-00 for xcon@ietf.org; Tue, 27 Jan 2004 09:07:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AlTrZ-0003bY-00 for xcon@ietf.org; Tue, 27 Jan 2004 09:06:45 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0RE6hY09146 for ; Tue, 27 Jan 2004 16:06:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 27 Jan 2004 16:06:37 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 27 Jan 2004 16:06:37 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 27 Jan 2004 16:06:36 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B18A@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPkHje51pRHYYDuTKiC6dSIBid6YQAv9pJw To: , , X-OriginalArrivalTime: 27 Jan 2004 14:06:37.0455 (UTC) FILETIME=[C75401F0:01C3E4DE] 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 is complex if we choose to make it so. A simple start, stop = and repeat times will suffice for now. If we realise the need to create = or adopt a separate and complex protocol for scheduling, then we can = take that issue up then. In the mean time, I suggest to keep it simple. = Many folks agreed that simple scheduling is needed and is not harmful. = The implementation will be optional. /Hisham > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 26.January.2004 17:02 > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni;=20 > Koskelainen Petri > (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hisham, > What I claimed that the example and the complexity of the=20 > issue where raised > as an objection and not as an agreement > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, January 26, 2004 4:34 PM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I believe there has been more voices for having scheduling=20 > information in a > conference policy than not. The issue was how complex do we make it. >=20 > iCal was introduced in the discussion as an indicator of how=20 > complex it can > be. >=20 > Perhaps I'm missing your point. What was the reason for your objection > again? >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 26.January.2004 14:45 > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni;=20 > > Koskelainen Petri > > (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Hisham, > > I can not understand why you conclude that there is a rough=20 > > consensus. I > > looked at this thread and there are mixed views. > > I would like to add that considering another protocol like=20 > > iCal points again > > to show that this is a different application.=20 > > I can agree to conference duration but I would recommend not=20 > > to get into > > future reservations > > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, January 26, 2004 1:43 PM > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Roni, > >=20 > > Your objection is noted, but I believe we have rough=20 > > consensus on this issue > > already. The most recent discussions on the list have already=20 > > tapped into > > the solution domain. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Even, Roni > > > Sent: 25.January.2004 15:44 > > > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hi, > > > Repeating myself I would like to state my objection, and I=20 > > > would suggest to > > > have conference reservation functionality not in the scope of=20 > > > conference > > > policy but maybe as an application functionality that we may=20 > > > consider as a > > > different working item. > > > Roni > > >=20 > > > ************************************* > > > Roni Even > > >=20 > > > 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=20 > > [mailto:petri.koskelainen@nokia.com] > > > Sent: Sunday, January 25, 2004 3:31 PM > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > >=20 > > > Back to the original question in this thread: > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > > If so, then we need to add a requirement. > > >=20 > > > I guess we can close this open issue now as rough consensus=20 > > seems to=20 > > > be that such a requirement is needed (at least for the=20 > > > start/stop/repeat > > > times). > > > Note that we don't have to design the actual solution yet=20 > > > (e.g. using iCal vs defining own format). > > >=20 > > > -- > > > Petri > > >=20 > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 21.January.2004 16:09 > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > I think we need to figure out where we are going on=20 > scheduling. > > > > >=20 > > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > > least specify start/stop times for conferences, and that if=20 > > > > > the start time is in the future, that is a reservation. > > > >=20 > > > > Agreed. > > > >=20 > > > > >=20 > > > > > What I want to discuss is, how far do we go, and what is=20 > > > > the end game? > > > > > I think we can agree that generalized scheduling is complex,=20 > > > > > and standards exist (iCal). So, the issue I want to=20 > discuss is: > > > > > if we allow simple scheduling (start/stop) now,=20 > > do we EVENTUALLY > > > > > allow complex scheduling? That implies=20 > > duplicating > > > significant > > > > > parts of e.g. iCal. > > > > >=20 > > > > > We could consider an alternative - explicitly support an iCal=20 > > > > > (actually iMIP) transaction now. =20 > > > > >=20 > > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > > iMIP) now (or maybe as a minimum). =20 > > > > >=20 > > > > > Or we could pull in some or all of calsch > > > >=20 > > > > If there is an XML schema already defined that we can use,=20 > > > then it is > > > > possible to embed that in CPCP. If you look at the solution=20 > > > > we are proposing (using XCAP), each feature, like=20 > > > conference-time, has its > > > own=20 > > > > XML namespace. > > > > We can take the iCal XML namespace and just drop it in there. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > >=20 > > > > > Brian > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Yes. > > > > > >=20 > > > > > > We all have weekly meetings with predefined start and stop=20 > > > > > > times. I think it is a valid use case for a user to=20 > create a=20 > > > > > > conference policy to satisfy this once and once only. > > > > > >=20 > > > > > > Regards, > > > > > > Hisham > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > > Koskelainen Petri > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > For that matter, is there a use case for end=20 > points (XCON)=20 > > > > > > > doing such complicated scheduling? Why don't we=20 > just take=20 > > > > > > > the bridge out of service? > > > > > > >=20 > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > >=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hisham, > > > > > > > >=20 > > > > > > > > The conference server is not mentioned in > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > framework=20 > > > > > > > > mentioned the > > > > > > > > conference policy server. As for reservation my=20 > > > view is that=20 > > > > > > > > reservation is > > > > > > > > starting an ad-hoc conference when the schedule=20 > time has=20 > > > > > > > > arrived and it > > > > > > > > should not be part of the conference policy.=20 > > Reservation is=20 > > > > > > > a separate > > > > > > > > application from the conference policy. I=20 > suggest that if=20 > > > > > > > you want to > > > > > > > > address it then we should have a separate=20 > element in the=20 > > > > > > > > frame work which > > > > > > > > will be a reservation server. > > > > > > > >=20 > > > > > > > > Roni > > > > > > > >=20 > > > > > > > > ************************************* > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > Polycom Israel > > > > > > > >=20 > > > > > > > > Tel: +972-3-9251200 > > > > > > > > Cell: +972-55-481099 > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > ******************************************* > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > To: roni.even@polycom.co.il;=20 > petri.koskelainen@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > No, the focus host (conference server) is the one that=20 > > > > > handles the > > > > > > > > reservations. The focus is only created and=20 > > > destroyed by the=20 > > > > > > > > conference > > > > > > > > server according to the start and stop times. > > > > > > > >=20 > > > > > > > > /Hisham > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > Even, Roni;=20 > > > > > > > > > Khartabil Hisham > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi Petri, > > > > > > > > > The CPS is a data storage that is used by the=20 > > > focus, so the=20 > > > > > > > > > focus will have > > > > > > > > > to handle the reservation > > > > > > > > > Roni > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > To: roni.even@polycom.co.il;=20 > > hisham.khartabil@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > > Hi Roni, > > > > > > > > >=20 > > > > > > > > > > My opinion is that the conference policy=20 > needs only a=20 > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > application to the focus. According to the=20 > conference=20 > > > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > not the right place for reservation. > > > > > > > > >=20 > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > > capability in protocol since we need the feature anyway in=20 > > > real-world=20 > > > > (either in CPCP or in some new mystery protocol between the=20 > > > user and the=20 > > > > > > > reservation application). > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -- > > > > > > > > > Petri > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > Regards > > > > > > > > > > Roni Even > > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > To: xcon@ietf.org > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > > current proposed solution has repeat times (eg:=20 > > > meeting repeats > > > weekly),=20 > > > > > > > there is no requirement for such. > > > > > > > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > > so, then we need to add a requirement. > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 27 09:39:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06469 for ; Tue, 27 Jan 2004 09:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUMf-0003ly-Sh for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 09:38:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0REcra9014499 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 09:38:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUMf-0003lm-MK for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:38:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06463 for ; Tue, 27 Jan 2004 09:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlUMd-0005SA-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 09:38:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlULd-0005Ox-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 09:37:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlUKq-0005Lw-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 09:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUKr-0003RM-92; Tue, 27 Jan 2004 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlUKe-0003NT-4F for xcon@optimus.ietf.org; Tue, 27 Jan 2004 09:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06420 for ; Tue, 27 Jan 2004 09:36:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlUKc-0005KY-00 for xcon@ietf.org; Tue, 27 Jan 2004 09:36:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlUJi-0005HK-00 for xcon@ietf.org; Tue, 27 Jan 2004 09:35:51 -0500 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 1AlUIu-0005Bu-00 for xcon@ietf.org; Tue, 27 Jan 2004 09:35:01 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jan 2004 16:34:26 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , "Even, Roni" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 27 Jan 2004 16:34:23 +0200 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=none autolearn=no version=2.60 Hi, If the start stop and repeat time are for knowledge and do not mean a reservation of any resource on the conferencing server than it is simple. Any other meaning for the parameters is not simple. Resources for multimedia conferences are not simple. if you have voice activated video switch conference or if you have a 4x4 mixed video there is a need for difference resource management. Even the number of different mixes you want to create make it more complicated. And of course Eric Burger's comment about the definition of scheduling is complex. Overall I see reservation as a separate application then ad-hoc conferences. 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Tuesday, January 27, 2004 4:07 PM To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times The issue is complex if we choose to make it so. A simple start, stop and repeat times will suffice for now. If we realise the need to create or adopt a separate and complex protocol for scheduling, then we can take that issue up then. In the mean time, I suggest to keep it simple. Many folks agreed that simple scheduling is needed and is not harmful. The implementation will be optional. /Hisham > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 26.January.2004 17:02 > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; > Koskelainen Petri > (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Hisham, > What I claimed that the example and the complexity of the > issue where raised > as an objection and not as an agreement > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, January 26, 2004 4:34 PM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > I believe there has been more voices for having scheduling > information in a > conference policy than not. The issue was how complex do we make it. > > iCal was introduced in the discussion as an indicator of how > complex it can > be. > > Perhaps I'm missing your point. What was the reason for your objection > again? > > /Hisham > > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 26.January.2004 14:45 > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; > > Koskelainen Petri > > (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Hisham, > > I can not understand why you conclude that there is a rough > > consensus. I > > looked at this thread and there are mixed views. > > I would like to add that considering another protocol like > > iCal points again > > to show that this is a different application. > > I can agree to conference duration but I would recommend not > > to get into > > future reservations > > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, January 26, 2004 1:43 PM > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Roni, > > > > Your objection is noted, but I believe we have rough > > consensus on this issue > > already. The most recent discussions on the list have already > > tapped into > > the solution domain. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > Behalf Of ext > > > Even, Roni > > > Sent: 25.January.2004 15:44 > > > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Hi, > > > Repeating myself I would like to state my objection, and I > > > would suggest to > > > have conference reservation functionality not in the scope of > > > conference > > > policy but maybe as an application functionality that we may > > > consider as a > > > different working item. > > > Roni > > > > > > ************************************* > > > Roni Even > > > > > > Polycom Israel > > > > > > Tel: +972-3-9251200 > > > Cell: +972-55-481099 > > > email:roni.even@polycom.co.il > > > ******************************************* > > > > > > > > > -----Original Message----- > > > From: petri.koskelainen@nokia.com > > [mailto:petri.koskelainen@nokia.com] > > > Sent: Sunday, January 25, 2004 3:31 PM > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Back to the original question in this thread: > > > > > > > > > > > > Do we see a need for such capability using CPCP? > > > > > > > > > If so, then we need to add a requirement. > > > > > > I guess we can close this open issue now as rough consensus > > seems to > > > be that such a requirement is needed (at least for the > > > start/stop/repeat > > > times). > > > Note that we don't have to design the actual solution yet > > > (e.g. using iCal vs defining own format). > > > > > > -- > > > Petri > > > > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 21.January.2004 16:09 > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > I think we need to figure out where we are going on > scheduling. > > > > > > > > > > First, let me say that I think we SHOULD allow CPCP to at > > > > > least specify start/stop times for conferences, and that if > > > > > the start time is in the future, that is a reservation. > > > > > > > > Agreed. > > > > > > > > > > > > > > What I want to discuss is, how far do we go, and what is > > > > the end game? > > > > > I think we can agree that generalized scheduling is complex, > > > > > and standards exist (iCal). So, the issue I want to > discuss is: > > > > > if we allow simple scheduling (start/stop) now, > > do we EVENTUALLY > > > > > allow complex scheduling? That implies > > duplicating > > > significant > > > > > parts of e.g. iCal. > > > > > > > > > > We could consider an alternative - explicitly support an iCal > > > > > (actually iMIP) transaction now. > > > > > > > > > > One could allow the iMIP Request/Reply only (ie subset of > > > > > iMIP) now (or maybe as a minimum). > > > > > > > > > > Or we could pull in some or all of calsch > > > > > > > > If there is an XML schema already defined that we can use, > > > then it is > > > > possible to embed that in CPCP. If you look at the solution > > > > we are proposing (using XCAP), each feature, like > > > conference-time, has its > > > own > > > > XML namespace. > > > > We can take the iCal XML namespace and just drop it in there. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > We all have weekly meetings with predefined start and stop > > > > > > times. I think it is a valid use case for a user to > create a > > > > > > conference policy to satisfy this once and once only. > > > > > > > > > > > > Regards, > > > > > > Hisham > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > > > > Koskelainen Petri > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > For that matter, is there a use case for end > points (XCON) > > > > > > > doing such complicated scheduling? Why don't we > just take > > > > > > > the bridge out of service? > > > > > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > > > > > The conference server is not mentioned in > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The > > framework > > > > > > > > mentioned the > > > > > > > > conference policy server. As for reservation my > > > view is that > > > > > > > > reservation is > > > > > > > > starting an ad-hoc conference when the schedule > time has > > > > > > > > arrived and it > > > > > > > > should not be part of the conference policy. > > Reservation is > > > > > > > a separate > > > > > > > > application from the conference policy. I > suggest that if > > > > > > > you want to > > > > > > > > address it then we should have a separate > element in the > > > > > > > > frame work which > > > > > > > > will be a reservation server. > > > > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > ************************************* > > > > > > > > Roni Even > > > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > Cell: +972-55-481099 > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > To: roni.even@polycom.co.il; > petri.koskelainen@nokia.com; > > > > > > > > xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the one that > > > > > handles the > > > > > > > > reservations. The focus is only created and > > > destroyed by the > > > > > > > > conference > > > > > > > > server according to the start and stop times. > > > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); > Even, Roni; > > > > > > > > > Khartabil Hisham > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > > > The CPS is a data storage that is used by the > > > focus, so the > > > > > > > > > focus will have > > > > > > > > > to handle the reservation > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > To: roni.even@polycom.co.il; > > hisham.khartabil@nokia.com; > > > > > > > > xcon@ietf.org > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > > > > > My opinion is that the conference policy > needs only a > > > > > > > > > > conference duration parameter if any. > > > > > > > > > > I think that reservation is an external > > > > > > > > > > application to the focus. According to the > conference > > > > > > > > > > framework the focus is using the information in the > > > > > > > > > > conference policy server and the focus is > > > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > I think it makes sense to have this (repeat time) > > > > capability in protocol since we need the feature anyway in > > > real-world > > > > (either in CPCP or in some new mystery protocol between the > > > user and the > > > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > To: xcon@ietf.org > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. Although the > > > > > > > current proposed solution has repeat times (eg: > > > meeting repeats > > > weekly), > > > > > > > there is no requirement for such. > > > > > > > > > > > > > > > > > > Do we see a need for such capability using CPCP? If > > > > so, then we need to add a requirement. > > > > > > _______________________________________________ > > > 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 Jan 27 10:25:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09511 for ; Tue, 27 Jan 2004 10:25:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlV59-0003zT-IX for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 10:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RFOp02015333 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 10:24:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlV59-0003zE-Cg for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 10:24:51 -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 KAA09414 for ; Tue, 27 Jan 2004 10:24:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlV57-0000pK-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 10:24:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlV4E-0000hq-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 10:23:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlV3M-0000bn-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 10:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlV3N-0003kI-79; Tue, 27 Jan 2004 10:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlV3G-0003jk-Qi for xcon@optimus.ietf.org; Tue, 27 Jan 2004 10:22:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09297 for ; Tue, 27 Jan 2004 10:22:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlV3E-0000ao-00 for xcon@ietf.org; Tue, 27 Jan 2004 10:22:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlV2H-0000Vd-00 for xcon@ietf.org; Tue, 27 Jan 2004 10:21:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AlV1J-0000Ro-00 for xcon@ietf.org; Tue, 27 Jan 2004 10:20:53 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0RFKqY05581 for ; Tue, 27 Jan 2004 17:20:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 27 Jan 2004 17:19:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 27 Jan 2004 17:19:38 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 27 Jan 2004 17:19:38 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B18C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPk4rOcR98IZbZFRliuj0T9Rhp03gABZnjw To: , , X-OriginalArrivalTime: 27 Jan 2004 15:19:38.0336 (UTC) FILETIME=[FA896600:01C3E4E8] 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 [why is the XCON reflector so slow?] Roni, Start time indicates to the focus when it should start inviting users = and/or allow users to join. Stop time indicates to the focus when it should terminate sessions with = users. Repeat time indicates when this process starts again. The other issue is scheduling and resource reservation as you define it: = why do you see that CPCP is not suitable to this and a separate protocol = is required? Why scheduling can't be part of the conference policy? (I'm = just trying to understand your point of view) Regards, Hisham > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 27.January.2004 16:34 > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni;=20 > Koskelainen Petri > (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hi, > If the start stop and repeat time are for knowledge and do not mean a > reservation of any resource on the conferencing server than=20 > it is simple. > Any other meaning for the parameters is not simple. Resources=20 > for multimedia > conferences are not simple. if you have voice activated video switch > conference or if you have a 4x4 mixed video there is a need=20 > for difference > resource management. Even the number of different mixes you=20 > want to create > make it more complicated.=20 > And of course Eric Burger's comment about the definition of=20 > scheduling is > complex. > Overall I see reservation as a separate application then=20 > ad-hoc conferences. > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, January 27, 2004 4:07 PM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > The issue is complex if we choose to make it so. A simple=20 > start, stop and > repeat times will suffice for now. If we realise the need to=20 > create or adopt > a separate and complex protocol for scheduling, then we can=20 > take that issue > up then. In the mean time, I suggest to keep it simple. Many=20 > folks agreed > that simple scheduling is needed and is not harmful. The=20 > implementation will > be optional. >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 26.January.2004 17:02 > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni;=20 > > Koskelainen Petri > > (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Hisham, > > What I claimed that the example and the complexity of the=20 > > issue where raised > > as an objection and not as an agreement > > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, January 26, 2004 4:34 PM > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > I believe there has been more voices for having scheduling=20 > > information in a > > conference policy than not. The issue was how complex do we make it. > >=20 > > iCal was introduced in the discussion as an indicator of how=20 > > complex it can > > be. > >=20 > > Perhaps I'm missing your point. What was the reason for=20 > your objection > > again? > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: 26.January.2004 14:45 > > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni;=20 > > > Koskelainen Petri > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hisham, > > > I can not understand why you conclude that there is a rough=20 > > > consensus. I > > > looked at this thread and there are mixed views. > > > I would like to add that considering another protocol like=20 > > > iCal points again > > > to show that this is a different application.=20 > > > I can agree to conference duration but I would recommend not=20 > > > to get into > > > future reservations > > > 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: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, January 26, 2004 1:43 PM > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Roni, > > >=20 > > > Your objection is noted, but I believe we have rough=20 > > > consensus on this issue > > > already. The most recent discussions on the list have already=20 > > > tapped into > > > the solution domain. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > Even, Roni > > > > Sent: 25.January.2004 15:44 > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > Hi, > > > > Repeating myself I would like to state my objection, and I=20 > > > > would suggest to > > > > have conference reservation functionality not in the scope of=20 > > > > conference > > > > policy but maybe as an application functionality that we may=20 > > > > consider as a > > > > different working item. > > > > Roni > > > >=20 > > > > ************************************* > > > > Roni Even > > > >=20 > > > > 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=20 > > > [mailto:petri.koskelainen@nokia.com] > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > To: xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > >=20 > > > > Back to the original question in this thread: > > > >=20 > > > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > > > If so, then we need to add a requirement. > > > >=20 > > > > I guess we can close this open issue now as rough consensus=20 > > > seems to=20 > > > > be that such a requirement is needed (at least for the=20 > > > > start/stop/repeat > > > > times). > > > > Note that we don't have to design the actual solution yet=20 > > > > (e.g. using iCal vs defining own format). > > > >=20 > > > > -- > > > > Petri > > > >=20 > > > > > > -----Original Message----- > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: 21.January.2004 16:09 > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > I think we need to figure out where we are going on=20 > > scheduling. > > > > > >=20 > > > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > > > least specify start/stop times for conferences, and that if=20 > > > > > > the start time is in the future, that is a reservation. > > > > >=20 > > > > > Agreed. > > > > >=20 > > > > > >=20 > > > > > > What I want to discuss is, how far do we go, and what is=20 > > > > > the end game? > > > > > > I think we can agree that generalized scheduling is=20 > complex,=20 > > > > > > and standards exist (iCal). So, the issue I want to=20 > > discuss is: > > > > > > if we allow simple scheduling (start/stop) now,=20 > > > do we EVENTUALLY > > > > > > allow complex scheduling? That implies=20 > > > duplicating > > > > significant > > > > > > parts of e.g. iCal. > > > > > >=20 > > > > > > We could consider an alternative - explicitly=20 > support an iCal=20 > > > > > > (actually iMIP) transaction now. =20 > > > > > >=20 > > > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > > > iMIP) now (or maybe as a minimum). =20 > > > > > >=20 > > > > > > Or we could pull in some or all of calsch > > > > >=20 > > > > > If there is an XML schema already defined that we can use,=20 > > > > then it is > > > > > possible to embed that in CPCP. If you look at the solution=20 > > > > > we are proposing (using XCAP), each feature, like=20 > > > > conference-time, has its > > > > own=20 > > > > > XML namespace. > > > > > We can take the iCal XML namespace and just drop it in there. > > > > >=20 > > > > > Regards, > > > > > Hisham > > > > >=20 > > > > > >=20 > > > > > > Brian > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Yes. > > > > > > >=20 > > > > > > > We all have weekly meetings with predefined start=20 > and stop=20 > > > > > > > times. I think it is a valid use case for a user to=20 > > create a=20 > > > > > > > conference policy to satisfy this once and once only. > > > > > > >=20 > > > > > > > Regards, > > > > > > > Hisham > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > > > Koskelainen Petri > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > For that matter, is there a use case for end=20 > > points (XCON)=20 > > > > > > > > doing such complicated scheduling? Why don't we=20 > > just take=20 > > > > > > > > the bridge out of service? > > > > > > > >=20 > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hisham, > > > > > > > > >=20 > > > > > > > > > The conference server is not mentioned in > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > > framework=20 > > > > > > > > > mentioned the > > > > > > > > > conference policy server. As for reservation my=20 > > > > view is that=20 > > > > > > > > > reservation is > > > > > > > > > starting an ad-hoc conference when the schedule=20 > > time has=20 > > > > > > > > > arrived and it > > > > > > > > > should not be part of the conference policy.=20 > > > Reservation is=20 > > > > > > > > a separate > > > > > > > > > application from the conference policy. I=20 > > suggest that if=20 > > > > > > > > you want to > > > > > > > > > address it then we should have a separate=20 > > element in the=20 > > > > > > > > > frame work which > > > > > > > > > will be a reservation server. > > > > > > > > >=20 > > > > > > > > > Roni > > > > > > > > >=20 > > > > > > > > > ************************************* > > > > > > > > > Roni Even > > > > > > > > >=20 > > > > > > > > > Polycom Israel > > > > > > > > >=20 > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > ******************************************* > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > To: roni.even@polycom.co.il;=20 > > petri.koskelainen@nokia.com;=20 > > > > > > > > > xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > No, the focus host (conference server) is the=20 > one that=20 > > > > > > handles the > > > > > > > > > reservations. The focus is only created and=20 > > > > destroyed by the=20 > > > > > > > > > conference > > > > > > > > > server according to the start and stop times. > > > > > > > > >=20 > > > > > > > > > /Hisham > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Even, Roni=20 > [mailto:roni.even@polycom.co.il] > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > > Even, Roni;=20 > > > > > > > > > > Khartabil Hisham > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > Hi Petri, > > > > > > > > > > The CPS is a data storage that is used by the=20 > > > > focus, so the=20 > > > > > > > > > > focus will have > > > > > > > > > > to handle the reservation > > > > > > > > > > Roni > > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > To: roni.even@polycom.co.il;=20 > > > hisham.khartabil@nokia.com;=20 > > > > > > > > > xcon@ietf.org > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > > >=20 > > > > > > > > > > Hi Roni, > > > > > > > > > >=20 > > > > > > > > > > > My opinion is that the conference policy=20 > > needs only a=20 > > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > > application to the focus. According to the=20 > > conference=20 > > > > > > > > > > > framework the focus is using the=20 > information in the=20 > > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > > not the right place for reservation. > > > > > > > > > >=20 > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > > > capability in protocol since we need the feature anyway in=20 > > > > real-world=20 > > > > > (either in CPCP or in some new mystery protocol between the=20 > > > > user and the=20 > > > > > > > > reservation application). > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > -- > > > > > > > > > > Petri > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > > Regards > > > > > > > > > > > Roni Even > > > > > > > > > > >=20 > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > > > current proposed solution has repeat times (eg:=20 > > > > meeting repeats > > > > weekly),=20 > > > > > > > > there is no requirement for such. > > > > > > > > > >=20 > > > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > > > so, then we need to add a requirement. > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 27 11:59:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13240 for ; Tue, 27 Jan 2004 11:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWY6-0001pz-3s for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 11:58:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RGwo7Y007062 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 11:58:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWY5-0001pp-VL for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 11:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13227 for ; Tue, 27 Jan 2004 11:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWY4-0006UF-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 11:58:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWX8-0006RV-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 11:57:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlWWL-0006Oq-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 11:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWWL-0001ii-3c; Tue, 27 Jan 2004 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWWA-0001hp-WE for xcon@optimus.ietf.org; Tue, 27 Jan 2004 11:56:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13171 for ; Tue, 27 Jan 2004 11:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWW9-0006Nd-00 for xcon@ietf.org; Tue, 27 Jan 2004 11:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWVD-0006Kj-00 for xcon@ietf.org; Tue, 27 Jan 2004 11:55:53 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AlWUN-0006FR-00 for xcon@ietf.org; Tue, 27 Jan 2004 11:54:59 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jan 2004 11:54:27 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6339@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , roni.even@polycom.co.il, petri.koskelainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 27 Jan 2004 11:54:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I point out that resource reservation is local to the server, and not subject to standardization. The actual request for the reservation (start/stop/repeat/#ports/media...) is. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, January 27, 2004 10:20 AM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > [why is the XCON reflector so slow?] > > Roni, > > Start time indicates to the focus when it should start > inviting users and/or allow users to join. > Stop time indicates to the focus when it should terminate > sessions with users. > Repeat time indicates when this process starts again. > > The other issue is scheduling and resource reservation as you > define it: why do you see that CPCP is not suitable to this > and a separate protocol is required? Why scheduling can't be > part of the conference policy? (I'm just trying to understand > your point of view) > > Regards, > Hisham > > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 27.January.2004 16:34 > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; > > Koskelainen Petri > > (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Hi, > > If the start stop and repeat time are for knowledge and do > not mean a > > reservation of any resource on the conferencing server than > > it is simple. > > Any other meaning for the parameters is not simple. Resources > > for multimedia > > conferences are not simple. if you have voice activated video switch > > conference or if you have a 4x4 mixed video there is a need > > for difference > > resource management. Even the number of different mixes you > > want to create > > make it more complicated. > > And of course Eric Burger's comment about the definition of > > scheduling is > > complex. > > Overall I see reservation as a separate application then > > ad-hoc conferences. > > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, January 27, 2004 4:07 PM > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > The issue is complex if we choose to make it so. A simple > > start, stop and > > repeat times will suffice for now. If we realise the need to > > create or adopt > > a separate and complex protocol for scheduling, then we can > > take that issue > > up then. In the mean time, I suggest to keep it simple. Many > > folks agreed > > that simple scheduling is needed and is not harmful. The > > implementation will > > be optional. > > > > /Hisham > > > > > -----Original Message----- > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: 26.January.2004 17:02 > > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; > > > Koskelainen Petri > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Hisham, > > > What I claimed that the example and the complexity of the > > > issue where raised > > > as an objection and not as an agreement > > > 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: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Monday, January 26, 2004 4:34 PM > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > > xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > I believe there has been more voices for having scheduling > > > information in a > > > conference policy than not. The issue was how complex do > we make it. > > > > > > iCal was introduced in the discussion as an indicator of how > > > complex it can > > > be. > > > > > > Perhaps I'm missing your point. What was the reason for > > your objection > > > again? > > > > > > /Hisham > > > > > > > -----Original Message----- > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: 26.January.2004 14:45 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; > > > > Koskelainen Petri > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Hisham, > > > > I can not understand why you conclude that there is a rough > > > > consensus. I > > > > looked at this thread and there are mixed views. > > > > I would like to add that considering another protocol like > > > > iCal points again > > > > to show that this is a different application. > > > > I can agree to conference duration but I would recommend not > > > > to get into > > > > future reservations > > > > 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: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Monday, January 26, 2004 1:43 PM > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > > > xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Roni, > > > > > > > > Your objection is noted, but I believe we have rough > > > > consensus on this issue > > > > already. The most recent discussions on the list have already > > > > tapped into > > > > the solution domain. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > Even, Roni > > > > > Sent: 25.January.2004 15:44 > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > Hi, > > > > > Repeating myself I would like to state my objection, and I > > > > > would suggest to > > > > > have conference reservation functionality not in the scope of > > > > > conference > > > > > policy but maybe as an application functionality that we may > > > > > consider as a > > > > > different working item. > > > > > Roni > > > > > > > > > > ************************************* > > > > > Roni Even > > > > > > > > > > Polycom Israel > > > > > > > > > > Tel: +972-3-9251200 > > > > > Cell: +972-55-481099 > > > > > email:roni.even@polycom.co.il > > > > > ******************************************* > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: petri.koskelainen@nokia.com > > > > [mailto:petri.koskelainen@nokia.com] > > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > > To: xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > Back to the original question in this thread: > > > > > > > > > > > > > > > > Do we see a need for such capability using CPCP? > > > > > > > > > > > If so, then we need to add a requirement. > > > > > > > > > > I guess we can close this open issue now as rough consensus > > > > seems to > > > > > be that such a requirement is needed (at least for the > > > > > start/stop/repeat > > > > > times). > > > > > Note that we don't have to design the actual solution yet > > > > > (e.g. using iCal vs defining own format). > > > > > > > > > > -- > > > > > Petri > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > Sent: 21.January.2004 16:09 > > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > I think we need to figure out where we are going on > > > scheduling. > > > > > > > > > > > > > > First, let me say that I think we SHOULD allow CPCP to at > > > > > > > least specify start/stop times for conferences, > and that if > > > > > > > the start time is in the future, that is a reservation. > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > What I want to discuss is, how far do we go, and what is > > > > > > the end game? > > > > > > > I think we can agree that generalized scheduling is > > complex, > > > > > > > and standards exist (iCal). So, the issue I want to > > > discuss is: > > > > > > > if we allow simple scheduling (start/stop) now, > > > > do we EVENTUALLY > > > > > > > allow complex scheduling? That implies > > > > duplicating > > > > > significant > > > > > > > parts of e.g. iCal. > > > > > > > > > > > > > > We could consider an alternative - explicitly > > support an iCal > > > > > > > (actually iMIP) transaction now. > > > > > > > > > > > > > > One could allow the iMIP Request/Reply only (ie subset of > > > > > > > iMIP) now (or maybe as a minimum). > > > > > > > > > > > > > > Or we could pull in some or all of calsch > > > > > > > > > > > > If there is an XML schema already defined that we can use, > > > > > then it is > > > > > > possible to embed that in CPCP. If you look at the solution > > > > > > we are proposing (using XCAP), each feature, like > > > > > conference-time, has its > > > > > own > > > > > > XML namespace. > > > > > > We can take the iCal XML namespace and just drop it > in there. > > > > > > > > > > > > Regards, > > > > > > Hisham > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > We all have weekly meetings with predefined start > > and stop > > > > > > > > times. I think it is a valid use case for a user to > > > create a > > > > > > > > conference policy to satisfy this once and once only. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Hisham > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > > > > > > Koskelainen Petri > > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > For that matter, is there a use case for end > > > points (XCON) > > > > > > > > > doing such complicated scheduling? Why don't we > > > just take > > > > > > > > > the bridge out of service? > > > > > > > > > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > > > > > > > > > The conference server is not mentioned in > > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The > > > > framework > > > > > > > > > > mentioned the > > > > > > > > > > conference policy server. As for reservation my > > > > > view is that > > > > > > > > > > reservation is > > > > > > > > > > starting an ad-hoc conference when the schedule > > > time has > > > > > > > > > > arrived and it > > > > > > > > > > should not be part of the conference policy. > > > > Reservation is > > > > > > > > > a separate > > > > > > > > > > application from the conference policy. I > > > suggest that if > > > > > > > > > you want to > > > > > > > > > > address it then we should have a separate > > > element in the > > > > > > > > > > frame work which > > > > > > > > > > will be a reservation server. > > > > > > > > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > ************************************* > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > > To: roni.even@polycom.co.il; > > > petri.koskelainen@nokia.com; > > > > > > > > > > xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the > > one that > > > > > > > handles the > > > > > > > > > > reservations. The focus is only created and > > > > > destroyed by the > > > > > > > > > > conference > > > > > > > > > > server according to the start and stop times. > > > > > > > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Even, Roni > > [mailto:roni.even@polycom.co.il] > > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); > > > Even, Roni; > > > > > > > > > > > Khartabil Hisham > > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > > > > > The CPS is a data storage that is used by the > > > > > focus, so the > > > > > > > > > > > focus will have > > > > > > > > > > > to handle the reservation > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > > To: roni.even@polycom.co.il; > > > > hisham.khartabil@nokia.com; > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > Repeat times > > > > > > > > > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > > > > > > > > > My opinion is that the conference policy > > > needs only a > > > > > > > > > > > > conference duration parameter if any. > > > > > > > > > > > > I think that reservation is an external > > > > > > > > > > > > application to the focus. According to the > > > conference > > > > > > > > > > > > framework the focus is using the > > information in the > > > > > > > > > > > > conference policy server and the focus is > > > > > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > > I think it makes sense to have this (repeat time) > > > > > > capability in protocol since we need the feature anyway in > > > > > real-world > > > > > > (either in CPCP or in some new mystery protocol between the > > > > > user and the > > > > > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. > Although the > > > > > > > > > current proposed solution has repeat times (eg: > > > > > meeting repeats > > > > > weekly), > > > > > > > > > there is no requirement for such. > > > > > > > > > > > > > > > > > > > > > > Do we see a need for such capability > using CPCP? If > > > > > > so, then we need to add a requirement. > > > > > > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 27 19:39:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06137 for ; Tue, 27 Jan 2004 19:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldjn-0007U1-5W for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 19:39:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0dN6d028759 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 19:39:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldjm-0007Tm-Vz for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:39:23 -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 TAA05933 for ; Tue, 27 Jan 2004 19:39:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldjl-0002p7-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 19:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldh5-00028x-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 19:36:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AldeF-0001ST-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 19:33:39 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRe-00062U-1N for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldGp-0001Cv-Sd; Tue, 27 Jan 2004 19:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlCPu-0003BB-N9 for xcon@optimus.ietf.org; Mon, 26 Jan 2004 14:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16670 for ; Mon, 26 Jan 2004 14:28:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlCPi-0007LV-00 for xcon@ietf.org; Mon, 26 Jan 2004 14:28:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlCMX-0007DO-00 for xcon@ietf.org; Mon, 26 Jan 2004 14:25:36 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AlCKq-00075V-00 for xcon@ietf.org; Mon, 26 Jan 2004 14:23:49 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 28286; Mon, 26 Jan 2004 14:25:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 26 Jan 2004 14:22:45 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB2424E@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPjSbi3pMFvfOcVSTOgmgHpIc0jOQA90fOQ From: "Eric Burger" To: Cc: "Even, Roni" 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I started to say that it was totally out of scope. Here are both sides = of the coin: AGAINST *ANY* SCHEDULING IN CPCP: Scheduling logic is arbitrarily complex. Scheduling semantics are = arbitrarily complex, and have been tackled in other venues much better = than we every will (e.g., iCal). What more does CPCP need other than = "Create conference NOW" and "Remove conference NOW"? FOR *SOME* SCHEDULING IN CPCP: Resource management should be at the focus, not at the application. = This would lead to "Reserve resources for a conference starting LATER" = (could succeed or fail). I *might* understand "Reserve resources for a conference that repeats = every {time unit}". I would NOT approve "Reserve resources for a conference that repeats = every week except for the week after next." Limit ourselves to "Reserve = resources for a conference this week and next. + Reserve resources for = a conference starting three weeks from now." > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Sunday, January 25, 2004 8:44 AM > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hi, > Repeating myself I would like to state my objection, and I=20 > would suggest to > have conference reservation functionality not in the scope of=20 > conference > policy but maybe as an application functionality that we may=20 > consider as a > different working item. > Roni >=20 > ************************************* > Roni Even >=20 > 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: Sunday, January 25, 2004 3:31 PM > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 >=20 > Back to the original question in this thread: >=20 > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > If so, then we need to add a requirement. >=20 > I guess we can close this open issue now as rough consensus seems to=20 > be that such a requirement is needed (at least for the=20 > start/stop/repeat > times). > Note that we don't have to design the actual solution yet=20 > (e.g. using iCal vs defining own format). >=20 > -- > Petri >=20 > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 21.January.2004 16:09 > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > I think we need to figure out where we are going on scheduling. > > >=20 > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > least specify start/stop times for conferences, and that if=20 > > > the start time is in the future, that is a reservation. > >=20 > > Agreed. > >=20 > > >=20 > > > What I want to discuss is, how far do we go, and what is=20 > > the end game? > > > I think we can agree that generalized scheduling is complex,=20 > > > and standards exist (iCal). So, the issue I want to discuss is: > > > if we allow simple scheduling (start/stop) now, do we EVENTUALLY > > > allow complex scheduling? That implies duplicating > significant > > > parts of e.g. iCal. > > >=20 > > > We could consider an alternative - explicitly support an iCal=20 > > > (actually iMIP) transaction now. =20 > > >=20 > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > iMIP) now (or maybe as a minimum). =20 > > >=20 > > > Or we could pull in some or all of calsch > >=20 > > If there is an XML schema already defined that we can use,=20 > then it is > > possible to embed that in CPCP. If you look at the solution=20 > > we are proposing (using XCAP), each feature, like=20 > conference-time, has its > own=20 > > XML namespace. > > We can take the iCal XML namespace and just drop it in there. > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > > Brian > > >=20 > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > Yes. > > > >=20 > > > > We all have weekly meetings with predefined start and stop=20 > > > > times. I think it is a valid use case for a user to create a=20 > > > > conference policy to satisfy this once and once only. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > Sent: 20.January.2004 18:01 > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > Koskelainen Petri > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > For that matter, is there a use case for end points (XCON)=20 > > > > > doing such complicated scheduling? Why don't we just take=20 > > > > > the bridge out of service? > > > > >=20 > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Hisham, > > > > > >=20 > > > > > > The conference server is not mentioned in > > > > > > draft-ietf-sipping-conferencing-framework-01. The framework=20 > > > > > > mentioned the > > > > > > conference policy server. As for reservation my=20 > view is that=20 > > > > > > reservation is > > > > > > starting an ad-hoc conference when the schedule time has=20 > > > > > > arrived and it > > > > > > should not be part of the conference policy. Reservation is=20 > > > > > a separate > > > > > > application from the conference policy. I suggest that if=20 > > > > > you want to > > > > > > address it then we should have a separate element in the=20 > > > > > > frame work which > > > > > > will be a reservation server. > > > > > >=20 > > > > > > Roni > > > > > >=20 > > > > > > ************************************* > > > > > > Roni Even > > > > > >=20 > > > > > > Polycom Israel > > > > > >=20 > > > > > > Tel: +972-3-9251200 > > > > > > Cell: +972-55-481099 > > > > > > email:roni.even@polycom.co.il > > > > > > ******************************************* > > > > > >=20 > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > > > > xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > No, the focus host (conference server) is the one that=20 > > > handles the > > > > > > reservations. The focus is only created and=20 > destroyed by the=20 > > > > > > conference > > > > > > server according to the start and stop times. > > > > > >=20 > > > > > > /Hisham > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > > > > > Khartabil Hisham > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi Petri, > > > > > > > The CPS is a data storage that is used by the=20 > focus, so the=20 > > > > > > > focus will have > > > > > > > to handle the reservation > > > > > > > Roni > > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;=20 > > > > > > xcon@ietf.org > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > > Hi Roni, > > > > > > >=20 > > > > > > > > My opinion is that the conference policy needs only a=20 > > > > > > > > conference duration parameter if any.=20 > > > > > > > > I think that reservation is an external=20 > > > > > > > > application to the focus. According to the conference=20 > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > conference policy server and the focus is=20 > > > > > > > > not the right place for reservation. > > > > > > >=20 > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > I think it makes sense to have this (repeat time)=20 > > capability in protocol since we need the feature anyway in=20 > real-world=20 > > (either in CPCP or in some new mystery protocol between the=20 > user and the=20 > > > > > reservation application). > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > -- > > > > > > > Petri > > > > > > >=20 > > > > > > >=20 > > > > > > > > Regards > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > To: xcon@ietf.org > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > >=20 > > > > > > >=20 > > > > > > > A conference has start and stop times. Although the=20 > > > > > current proposed solution has repeat times (eg:=20 > meeting repeats > weekly),=20 > > > > > there is no requirement for such. > > > > > > >=20 > > > > > > > Do we see a need for such capability using CPCP? If=20 > > so, then we need to add a requirement. >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Jan 27 20:11:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07740 for ; Tue, 27 Jan 2004 20:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleEV-0000rt-Lp for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 20:11:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1B7vP003330 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 20:11:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleEV-0000rd-4C for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:11: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 UAA07724 for ; Tue, 27 Jan 2004 20:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleET-0005If-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 20:11:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleDZ-0005Fo-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 20:10:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AleCn-0005Cl-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 20:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald4y-0005G3-Hl; Tue, 27 Jan 2004 18:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al8HZ-0001kl-FE for xcon@optimus.ietf.org; Mon, 26 Jan 2004 10:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07986 for ; Mon, 26 Jan 2004 10:04:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8HX-0001za-00 for xcon@ietf.org; Mon, 26 Jan 2004 10:04:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8Gb-0001ws-00 for xcon@ietf.org; Mon, 26 Jan 2004 10:03:10 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1Al8GK-0001tz-00 for xcon@ietf.org; Mon, 26 Jan 2004 10:02:52 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jan 2004 17:02:20 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , "Even, Roni" , petri.koskelainen@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 26 Jan 2004 17:02:19 +0200 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=none autolearn=no version=2.60 Hisham, What I claimed that the example and the complexity of the issue where raised as an objection and not as an agreement 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Monday, January 26, 2004 4:34 PM To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times I believe there has been more voices for having scheduling information in a conference policy than not. The issue was how complex do we make it. iCal was introduced in the discussion as an indicator of how complex it can be. Perhaps I'm missing your point. What was the reason for your objection again? /Hisham > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 26.January.2004 14:45 > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni; > Koskelainen Petri > (Nokia-NRC/Tampere); xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Hisham, > I can not understand why you conclude that there is a rough > consensus. I > looked at this thread and there are mixed views. > I would like to add that considering another protocol like > iCal points again > to show that this is a different application. > I can agree to conference duration but I would recommend not > to get into > future reservations > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, January 26, 2004 1:43 PM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Roni, > > Your objection is noted, but I believe we have rough > consensus on this issue > already. The most recent discussions on the list have already > tapped into > the solution domain. > > Regards, > Hisham > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext > > Even, Roni > > Sent: 25.January.2004 15:44 > > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Hi, > > Repeating myself I would like to state my objection, and I > > would suggest to > > have conference reservation functionality not in the scope of > > conference > > policy but maybe as an application functionality that we may > > consider as a > > different working item. > > Roni > > > > ************************************* > > Roni Even > > > > Polycom Israel > > > > Tel: +972-3-9251200 > > Cell: +972-55-481099 > > email:roni.even@polycom.co.il > > ******************************************* > > > > > > -----Original Message----- > > From: petri.koskelainen@nokia.com > [mailto:petri.koskelainen@nokia.com] > > Sent: Sunday, January 25, 2004 3:31 PM > > To: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > Back to the original question in this thread: > > > > > > > > > > Do we see a need for such capability using CPCP? > > > > > > > > If so, then we need to add a requirement. > > > > I guess we can close this open issue now as rough consensus > seems to > > be that such a requirement is needed (at least for the > > start/stop/repeat > > times). > > Note that we don't have to design the actual solution yet > > (e.g. using iCal vs defining own format). > > > > -- > > Petri > > > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 21.January.2004 16:09 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > I think we need to figure out where we are going on scheduling. > > > > > > > > First, let me say that I think we SHOULD allow CPCP to at > > > > least specify start/stop times for conferences, and that if > > > > the start time is in the future, that is a reservation. > > > > > > Agreed. > > > > > > > > > > > What I want to discuss is, how far do we go, and what is > > > the end game? > > > > I think we can agree that generalized scheduling is complex, > > > > and standards exist (iCal). So, the issue I want to discuss is: > > > > if we allow simple scheduling (start/stop) now, > do we EVENTUALLY > > > > allow complex scheduling? That implies > duplicating > > significant > > > > parts of e.g. iCal. > > > > > > > > We could consider an alternative - explicitly support an iCal > > > > (actually iMIP) transaction now. > > > > > > > > One could allow the iMIP Request/Reply only (ie subset of > > > > iMIP) now (or maybe as a minimum). > > > > > > > > Or we could pull in some or all of calsch > > > > > > If there is an XML schema already defined that we can use, > > then it is > > > possible to embed that in CPCP. If you look at the solution > > > we are proposing (using XCAP), each feature, like > > conference-time, has its > > own > > > XML namespace. > > > We can take the iCal XML namespace and just drop it in there. > > > > > > Regards, > > > Hisham > > > > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > Yes. > > > > > > > > > > We all have weekly meetings with predefined start and stop > > > > > times. I think it is a valid use case for a user to create a > > > > > conference policy to satisfy this once and once only. > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > Sent: 20.January.2004 18:01 > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > > > Koskelainen Petri > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > For that matter, is there a use case for end points (XCON) > > > > > > doing such complicated scheduling? Why don't we just take > > > > > > the bridge out of service? > > > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > > > The conference server is not mentioned in > > > > > > > draft-ietf-sipping-conferencing-framework-01. The > framework > > > > > > > mentioned the > > > > > > > conference policy server. As for reservation my > > view is that > > > > > > > reservation is > > > > > > > starting an ad-hoc conference when the schedule time has > > > > > > > arrived and it > > > > > > > should not be part of the conference policy. > Reservation is > > > > > > a separate > > > > > > > application from the conference policy. I suggest that if > > > > > > you want to > > > > > > > address it then we should have a separate element in the > > > > > > > frame work which > > > > > > > will be a reservation server. > > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > ************************************* > > > > > > > Roni Even > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > Cell: +972-55-481099 > > > > > > > email:roni.even@polycom.co.il > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com; > > > > > > > xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the one that > > > > handles the > > > > > > > reservations. The focus is only created and > > destroyed by the > > > > > > > conference > > > > > > > server according to the start and stop times. > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni; > > > > > > > > Khartabil Hisham > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > > The CPS is a data storage that is used by the > > focus, so the > > > > > > > > focus will have > > > > > > > > to handle the reservation > > > > > > > > Roni > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > To: roni.even@polycom.co.il; > hisham.khartabil@nokia.com; > > > > > > > xcon@ietf.org > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > > > My opinion is that the conference policy needs only a > > > > > > > > > conference duration parameter if any. > > > > > > > > > I think that reservation is an external > > > > > > > > > application to the focus. According to the conference > > > > > > > > > framework the focus is using the information in the > > > > > > > > > conference policy server and the focus is > > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > I think it makes sense to have this (repeat time) > > > capability in protocol since we need the feature anyway in > > real-world > > > (either in CPCP or in some new mystery protocol between the > > user and the > > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > To: xcon@ietf.org > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. Although the > > > > > > current proposed solution has repeat times (eg: > > meeting repeats > > weekly), > > > > > > there is no requirement for such. > > > > > > > > > > > > > > > > Do we see a need for such capability using CPCP? If > > > so, then we need to add a requirement. > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 28 02:35:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17391 for ; Wed, 28 Jan 2004 02:35:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkDZ-0005jz-S5 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 02:34:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S7YXJP022066 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 02:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkDZ-0005jl-GS for xcon-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 02:34:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17355 for ; Wed, 28 Jan 2004 02:34:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlkDV-0001nD-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 02:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlkCc-0001i6-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 02:33:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlkC4-0001cL-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 02:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkC5-0005eZ-AW; Wed, 28 Jan 2004 02:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlkBO-0005NN-Sy for xcon@optimus.ietf.org; Wed, 28 Jan 2004 02:32:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17075 for ; Wed, 28 Jan 2004 02:32:15 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlkBK-0001X9-00 for xcon@ietf.org; Wed, 28 Jan 2004 02:32:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlkAN-0001NB-00 for xcon@ietf.org; Wed, 28 Jan 2004 02:31:17 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Alk9S-0001Gy-00 for xcon@ietf.org; Wed, 28 Jan 2004 02:30:18 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0S7UIY18025 for ; Wed, 28 Jan 2004 09:30:18 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 09:30:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 09:30:04 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 28 Jan 2004 09:30:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B18E@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPjSbi3pMFvfOcVSTOgmgHpIc0jOQA90fOQAEvBJTA= To: , Cc: X-OriginalArrivalTime: 28 Jan 2004 07:30:04.0892 (UTC) FILETIME=[8C44C1C0:01C3E570] 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 I'm sorry, but I don't buy the argument that just because scheduling is = complex it requires a separate protocol. Henning did mention how they = approached the problem for CPL. We can adopt that here also. If we don't want a full scheduling solution yet, then we start with = something basic and design the protocol in a way that allows complex = scheduling to be added later. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: 26.January.2004 21:23 > To: xcon@ietf.org > Cc: Even, Roni > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I started to say that it was totally out of scope. Here are=20 > both sides of the coin: >=20 > AGAINST *ANY* SCHEDULING IN CPCP: > Scheduling logic is arbitrarily complex. Scheduling=20 > semantics are arbitrarily complex, and have been tackled in=20 > other venues much better than we every will (e.g., iCal). =20 > What more does CPCP need other than "Create conference NOW"=20 > and "Remove conference NOW"? >=20 > FOR *SOME* SCHEDULING IN CPCP: > Resource management should be at the focus, not at the=20 > application. This would lead to "Reserve resources for a=20 > conference starting LATER" (could succeed or fail). >=20 > I *might* understand "Reserve resources for a conference that=20 > repeats every {time unit}". >=20 > I would NOT approve "Reserve resources for a conference that=20 > repeats every week except for the week after next." Limit=20 > ourselves to "Reserve resources for a conference this week=20 > and next. + Reserve resources for a conference starting=20 > three weeks from now." >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Sunday, January 25, 2004 8:44 AM > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Hi, > > Repeating myself I would like to state my objection, and I=20 > > would suggest to > > have conference reservation functionality not in the scope of=20 > > conference > > policy but maybe as an application functionality that we may=20 > > consider as a > > different working item. > > Roni > >=20 > > ************************************* > > Roni Even > >=20 > > 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=20 > [mailto:petri.koskelainen@nokia.com] > > Sent: Sunday, January 25, 2004 3:31 PM > > To: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > >=20 > > Back to the original question in this thread: > >=20 > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > If so, then we need to add a requirement. > >=20 > > I guess we can close this open issue now as rough consensus=20 > seems to=20 > > be that such a requirement is needed (at least for the=20 > > start/stop/repeat > > times). > > Note that we don't have to design the actual solution yet=20 > > (e.g. using iCal vs defining own format). > >=20 > > -- > > Petri > >=20 > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 21.January.2004 16:09 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > I think we need to figure out where we are going on scheduling. > > > >=20 > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > least specify start/stop times for conferences, and that if=20 > > > > the start time is in the future, that is a reservation. > > >=20 > > > Agreed. > > >=20 > > > >=20 > > > > What I want to discuss is, how far do we go, and what is=20 > > > the end game? > > > > I think we can agree that generalized scheduling is complex,=20 > > > > and standards exist (iCal). So, the issue I want to discuss is: > > > > if we allow simple scheduling (start/stop) now,=20 > do we EVENTUALLY > > > > allow complex scheduling? That implies=20 > duplicating > > significant > > > > parts of e.g. iCal. > > > >=20 > > > > We could consider an alternative - explicitly support an iCal=20 > > > > (actually iMIP) transaction now. =20 > > > >=20 > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > iMIP) now (or maybe as a minimum). =20 > > > >=20 > > > > Or we could pull in some or all of calsch > > >=20 > > > If there is an XML schema already defined that we can use,=20 > > then it is > > > possible to embed that in CPCP. If you look at the solution=20 > > > we are proposing (using XCAP), each feature, like=20 > > conference-time, has its > > own=20 > > > XML namespace. > > > We can take the iCal XML namespace and just drop it in there. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > >=20 > > > > Brian > > > >=20 > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com=20 > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > Yes. > > > > >=20 > > > > > We all have weekly meetings with predefined start and stop=20 > > > > > times. I think it is a valid use case for a user to create a=20 > > > > > conference policy to satisfy this once and once only. > > > > >=20 > > > > > Regards, > > > > > Hisham > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > Sent: 20.January.2004 18:01 > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > Koskelainen Petri > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > For that matter, is there a use case for end points (XCON)=20 > > > > > > doing such complicated scheduling? Why don't we just take=20 > > > > > > the bridge out of service? > > > > > >=20 > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > >=20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Hisham, > > > > > > >=20 > > > > > > > The conference server is not mentioned in > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > framework=20 > > > > > > > mentioned the > > > > > > > conference policy server. As for reservation my=20 > > view is that=20 > > > > > > > reservation is > > > > > > > starting an ad-hoc conference when the schedule time has=20 > > > > > > > arrived and it > > > > > > > should not be part of the conference policy.=20 > Reservation is=20 > > > > > > a separate > > > > > > > application from the conference policy. I suggest that if=20 > > > > > > you want to > > > > > > > address it then we should have a separate element in the=20 > > > > > > > frame work which > > > > > > > will be a reservation server. > > > > > > >=20 > > > > > > > Roni > > > > > > >=20 > > > > > > > ************************************* > > > > > > > Roni Even > > > > > > >=20 > > > > > > > Polycom Israel > > > > > > >=20 > > > > > > > Tel: +972-3-9251200 > > > > > > > Cell: +972-55-481099 > > > > > > > email:roni.even@polycom.co.il > > > > > > > ******************************************* > > > > > > >=20 > > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > > > > > > xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > No, the focus host (conference server) is the one that=20 > > > > handles the > > > > > > > reservations. The focus is only created and=20 > > destroyed by the=20 > > > > > > > conference > > > > > > > server according to the start and stop times. > > > > > > >=20 > > > > > > > /Hisham > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;=20 > > > > > > > > Khartabil Hisham > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi Petri, > > > > > > > > The CPS is a data storage that is used by the=20 > > focus, so the=20 > > > > > > > > focus will have > > > > > > > > to handle the reservation > > > > > > > > Roni > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > To: roni.even@polycom.co.il;=20 > hisham.khartabil@nokia.com;=20 > > > > > > > xcon@ietf.org > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > > Hi Roni, > > > > > > > >=20 > > > > > > > > > My opinion is that the conference policy needs only a=20 > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > application to the focus. According to the conference=20 > > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > not the right place for reservation. > > > > > > > >=20 > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > capability in protocol since we need the feature anyway in=20 > > real-world=20 > > > (either in CPCP or in some new mystery protocol between the=20 > > user and the=20 > > > > > > reservation application). > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -- > > > > > > > > Petri > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > Regards > > > > > > > > > Roni Even > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > To: xcon@ietf.org > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > current proposed solution has repeat times (eg:=20 > > meeting repeats > > weekly),=20 > > > > > > there is no requirement for such. > > > > > > > >=20 > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > so, then we need to add a requirement. > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 > >=20 >=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 Wed Jan 28 06:53:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27101 for ; Wed, 28 Jan 2004 06:53:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloGC-000850-Oq for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 06:53:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SBrWpf031052 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 06:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloGC-00084l-Jw for xcon-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 06:53:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27094 for ; Wed, 28 Jan 2004 06:53:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloG8-0000si-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 06:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AloFM-0000oZ-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 06:52:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AloEg-0000ip-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 06:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloEj-000818-CC; Wed, 28 Jan 2004 06:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloEg-00080x-8Y for xcon@optimus.ietf.org; Wed, 28 Jan 2004 06:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26988 for ; Wed, 28 Jan 2004 06:51:53 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloEc-0000iD-00 for xcon@ietf.org; Wed, 28 Jan 2004 06:51:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AloDb-0000aV-00 for xcon@ietf.org; Wed, 28 Jan 2004 06:50:53 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AloCi-0000Sz-00 for xcon@ietf.org; Wed, 28 Jan 2004 06:49:56 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SBnvY02680 for ; Wed, 28 Jan 2004 13:49:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 13:49:56 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 13:49:56 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 28 Jan 2004 13:49:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B190@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPjSbi3pMFvfOcVSTOgmgHpIc0jOQA90fOQAEvBJTAACJlw0A== To: , Cc: X-OriginalArrivalTime: 28 Jan 2004 11:49:56.0091 (UTC) FILETIME=[D958ECB0:01C3E594] 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 Let me elaborate a little on this proposal. I agree that eventually we need complex scheduling for conferences. We = can pick this up after we finalise a solution for CPCP. In can be = decided at that point if this scheduling could be done inside CPCP as an = extension (similar approach to CPL) or is a separate protocol. In the mean time, we can define a very simple start, stop and repeat = times that is OPTIONAL TO IMPLEMENT at the client side. The purpose of = those would not be to indicate the need for resource reservation, = although they can be used for that. Start time indicates to the focus when it should start allowing users to = join or when it should invite users to join. Stop time indicates to the focus when it should stop allowing users to = join. It also indicates that the focus should not invite users that have = been added to dial-out list. Repeat times is obvious. Again, this would be optional and can be deprecated by a more complex = scheduling solution. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 28.January.2004 09:30 > To: eburger@snowshore.com; xcon@ietf.org > Cc: roni.even@polycom.co.il > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I'm sorry, but I don't buy the argument that just because=20 > scheduling is complex it requires a separate protocol.=20 > Henning did mention how they approached the problem for CPL.=20 > We can adopt that here also. >=20 > If we don't want a full scheduling solution yet, then we=20 > start with something basic and design the protocol in a way=20 > that allows complex scheduling to be added later. >=20 > /Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: 26.January.2004 21:23 > > To: xcon@ietf.org > > Cc: Even, Roni > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > I started to say that it was totally out of scope. Here are=20 > > both sides of the coin: > >=20 > > AGAINST *ANY* SCHEDULING IN CPCP: > > Scheduling logic is arbitrarily complex. Scheduling=20 > > semantics are arbitrarily complex, and have been tackled in=20 > > other venues much better than we every will (e.g., iCal). =20 > > What more does CPCP need other than "Create conference NOW"=20 > > and "Remove conference NOW"? > >=20 > > FOR *SOME* SCHEDULING IN CPCP: > > Resource management should be at the focus, not at the=20 > > application. This would lead to "Reserve resources for a=20 > > conference starting LATER" (could succeed or fail). > >=20 > > I *might* understand "Reserve resources for a conference that=20 > > repeats every {time unit}". > >=20 > > I would NOT approve "Reserve resources for a conference that=20 > > repeats every week except for the week after next." Limit=20 > > ourselves to "Reserve resources for a conference this week=20 > > and next. + Reserve resources for a conference starting=20 > > three weeks from now." > >=20 > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: Sunday, January 25, 2004 8:44 AM > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hi, > > > Repeating myself I would like to state my objection, and I=20 > > > would suggest to > > > have conference reservation functionality not in the scope of=20 > > > conference > > > policy but maybe as an application functionality that we may=20 > > > consider as a > > > different working item. > > > Roni > > >=20 > > > ************************************* > > > Roni Even > > >=20 > > > 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=20 > > [mailto:petri.koskelainen@nokia.com] > > > Sent: Sunday, January 25, 2004 3:31 PM > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > >=20 > > > Back to the original question in this thread: > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > > If so, then we need to add a requirement. > > >=20 > > > I guess we can close this open issue now as rough consensus=20 > > seems to=20 > > > be that such a requirement is needed (at least for the=20 > > > start/stop/repeat > > > times). > > > Note that we don't have to design the actual solution yet=20 > > > (e.g. using iCal vs defining own format). > > >=20 > > > -- > > > Petri > > >=20 > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 21.January.2004 16:09 > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > I think we need to figure out where we are going on=20 > scheduling. > > > > >=20 > > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > > least specify start/stop times for conferences, and that if=20 > > > > > the start time is in the future, that is a reservation. > > > >=20 > > > > Agreed. > > > >=20 > > > > >=20 > > > > > What I want to discuss is, how far do we go, and what is=20 > > > > the end game? > > > > > I think we can agree that generalized scheduling is complex,=20 > > > > > and standards exist (iCal). So, the issue I want to=20 > discuss is: > > > > > if we allow simple scheduling (start/stop) now,=20 > > do we EVENTUALLY > > > > > allow complex scheduling? That implies=20 > > duplicating > > > significant > > > > > parts of e.g. iCal. > > > > >=20 > > > > > We could consider an alternative - explicitly support an iCal=20 > > > > > (actually iMIP) transaction now. =20 > > > > >=20 > > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > > iMIP) now (or maybe as a minimum). =20 > > > > >=20 > > > > > Or we could pull in some or all of calsch > > > >=20 > > > > If there is an XML schema already defined that we can use,=20 > > > then it is > > > > possible to embed that in CPCP. If you look at the solution=20 > > > > we are proposing (using XCAP), each feature, like=20 > > > conference-time, has its > > > own=20 > > > > XML namespace. > > > > We can take the iCal XML namespace and just drop it in there. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > >=20 > > > > > Brian > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Yes. > > > > > >=20 > > > > > > We all have weekly meetings with predefined start and stop=20 > > > > > > times. I think it is a valid use case for a user to=20 > create a=20 > > > > > > conference policy to satisfy this once and once only. > > > > > >=20 > > > > > > Regards, > > > > > > Hisham > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > > Koskelainen Petri > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > For that matter, is there a use case for end=20 > points (XCON)=20 > > > > > > > doing such complicated scheduling? Why don't we=20 > just take=20 > > > > > > > the bridge out of service? > > > > > > >=20 > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > >=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hisham, > > > > > > > >=20 > > > > > > > > The conference server is not mentioned in > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > framework=20 > > > > > > > > mentioned the > > > > > > > > conference policy server. As for reservation my=20 > > > view is that=20 > > > > > > > > reservation is > > > > > > > > starting an ad-hoc conference when the schedule=20 > time has=20 > > > > > > > > arrived and it > > > > > > > > should not be part of the conference policy.=20 > > Reservation is=20 > > > > > > > a separate > > > > > > > > application from the conference policy. I=20 > suggest that if=20 > > > > > > > you want to > > > > > > > > address it then we should have a separate=20 > element in the=20 > > > > > > > > frame work which > > > > > > > > will be a reservation server. > > > > > > > >=20 > > > > > > > > Roni > > > > > > > >=20 > > > > > > > > ************************************* > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > Polycom Israel > > > > > > > >=20 > > > > > > > > Tel: +972-3-9251200 > > > > > > > > Cell: +972-55-481099 > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > ******************************************* > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > To: roni.even@polycom.co.il;=20 > petri.koskelainen@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > No, the focus host (conference server) is the one that=20 > > > > > handles the > > > > > > > > reservations. The focus is only created and=20 > > > destroyed by the=20 > > > > > > > > conference > > > > > > > > server according to the start and stop times. > > > > > > > >=20 > > > > > > > > /Hisham > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > Even, Roni;=20 > > > > > > > > > Khartabil Hisham > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi Petri, > > > > > > > > > The CPS is a data storage that is used by the=20 > > > focus, so the=20 > > > > > > > > > focus will have > > > > > > > > > to handle the reservation > > > > > > > > > Roni > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > To: roni.even@polycom.co.il;=20 > > hisham.khartabil@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > > Hi Roni, > > > > > > > > >=20 > > > > > > > > > > My opinion is that the conference policy=20 > needs only a=20 > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > application to the focus. According to the=20 > conference=20 > > > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > not the right place for reservation. > > > > > > > > >=20 > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > > capability in protocol since we need the feature anyway in=20 > > > real-world=20 > > > > (either in CPCP or in some new mystery protocol between the=20 > > > user and the=20 > > > > > > > reservation application). > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -- > > > > > > > > > Petri > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > Regards > > > > > > > > > > Roni Even > > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > To: xcon@ietf.org > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > > current proposed solution has repeat times (eg:=20 > > > meeting repeats > > > weekly),=20 > > > > > > > there is no requirement for such. > > > > > > > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > > so, then we need to add a requirement. > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 28 08:34:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00343 for ; Wed, 28 Jan 2004 08:34:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpox-0006H4-Qp for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 08:33:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SDXVSo024103 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 08:33:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpox-0006G4-HQ for xcon-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 08:33:31 -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 IAA00323 for ; Wed, 28 Jan 2004 08:33:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alpow-0001VS-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 08:33:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alpo0-0001R2-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 08:32:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlpnV-0001Mv-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 08:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpnW-0005wg-0f; Wed, 28 Jan 2004 08:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlpnB-0005tC-5g for xcon@optimus.ietf.org; Wed, 28 Jan 2004 08:31:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00275 for ; Wed, 28 Jan 2004 08:31:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alpn9-0001MW-00 for xcon@ietf.org; Wed, 28 Jan 2004 08:31:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlpmF-0001Hl-00 for xcon@ietf.org; Wed, 28 Jan 2004 08:30:43 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1Alplm-0001CD-00 for xcon@ietf.org; Wed, 28 Jan 2004 08:30:14 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i0SDU1IJ005239; Wed, 28 Jan 2004 08:30:02 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i0SDTuc05336; Wed, 28 Jan 2004 08:29:57 -0500 Message-ID: <4017B950.9030704@cs.columbia.edu> Date: Wed, 28 Jan 2004 08:29:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: eburger@snowshore.com, xcon@ietf.org, roni.even@polycom.co.il Subject: Re: [XCON] CPCP Requirement: Repeat times References: <2038BCC78B1AD641891A0D1AE133DBB70118B18E@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B18E@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > If we don't want a full scheduling solution yet, then we start with > something basic and design the protocol in a way that allows complex > scheduling to be added later. It's unclear to me what value repeat times add. They are just an abbreviation for having several instances. Repeat times make sense for a human user, but CPCP is likely at least one layer of indirection removed from a GUI. The problem with repeat times is that things get messy quickly, even for the seemingly trivial cases. Random example: conference repeats once a week at 9 am. However, daylight savings time happens during the repeats. If you just repeat every 86400*7 seconds, suddenly your conference starts an hour earlier or later than you had planned on. Thus, you now need to make sure you encode timezones correctly, plus making the implementation messier and more error-prone, for no additional functional capability that couldn't have been expressed by just enumerating the instances. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 28 09:09:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01400 for ; Wed, 28 Jan 2004 09:09:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqMt-0000Gb-K3 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 09:08:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SE8Zvq001019 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 09:08:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqMt-0000GM-BC for xcon-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 09:08:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01394 for ; Wed, 28 Jan 2004 09:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlqMr-0004Bd-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 09:08:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlqLx-00047m-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 09:07:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlqLN-000432-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 09:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqLN-0008HI-MU; Wed, 28 Jan 2004 09:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqKs-0008GI-Uq for xcon@optimus.ietf.org; Wed, 28 Jan 2004 09:06:31 -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 JAA01363 for ; Wed, 28 Jan 2004 09:06:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlqKr-00041m-00 for xcon@ietf.org; Wed, 28 Jan 2004 09:06:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlqJs-0003xf-00 for xcon@ietf.org; Wed, 28 Jan 2004 09:05:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AlqIt-0003qR-00 for xcon@ietf.org; Wed, 28 Jan 2004 09:04:27 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SE4PV02482 for ; Wed, 28 Jan 2004 16:04:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 Jan 2004 16:03:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 16:03:56 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 28 Jan 2004 16:03:54 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797672@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPlouFUIOwDeuB6TxOOSyKr8hzVMAABJtEA To: Cc: , , X-OriginalArrivalTime: 28 Jan 2004 14:03:56.0358 (UTC) FILETIME=[91B84E60:01C3E5A7] 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 Ok, I agree that there is no need to repeat time at this stage. /Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 28.January.2004 15:30 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Cc: eburger@snowshore.com; xcon@ietf.org; roni.even@polycom.co.il > Subject: Re: [XCON] CPCP Requirement: Repeat times >=20 >=20 > > If we don't want a full scheduling solution yet, then we start with > > something basic and design the protocol in a way that allows complex > > scheduling to be added later. >=20 > It's unclear to me what value repeat times add. They are just an=20 > abbreviation for having several instances. Repeat times make=20 > sense for a=20 > human user, but CPCP is likely at least one layer of=20 > indirection removed=20 > from a GUI. The problem with repeat times is that things get messy=20 > quickly, even for the seemingly trivial cases. Random example:=20 > conference repeats once a week at 9 am. However, daylight=20 > savings time=20 > happens during the repeats. If you just repeat every 86400*7 seconds,=20 > suddenly your conference starts an hour earlier or later than you had=20 > planned on. Thus, you now need to make sure you encode timezones=20 > correctly, plus making the implementation messier and more=20 > error-prone,=20 > for no additional functional capability that couldn't have been=20 > expressed by just enumerating the instances. >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Jan 28 09:43:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02237 for ; Wed, 28 Jan 2004 09:43:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alqtv-00038A-BN for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 09:42:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SEghRB012031 for xcon-archive@odin.ietf.org; Wed, 28 Jan 2004 09:42:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alqtu-00037y-NJ for xcon-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 09:42:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02230 for ; Wed, 28 Jan 2004 09:42:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alqts-0006kn-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 09:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alqsw-0006f1-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 09:41:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlqsI-0006Zt-00 for xcon-web-archive@ietf.org; Wed, 28 Jan 2004 09:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqsI-0002kr-7h; Wed, 28 Jan 2004 09:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alqry-0002gt-Or for xcon@optimus.ietf.org; Wed, 28 Jan 2004 09:40:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02180 for ; Wed, 28 Jan 2004 09:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alqrw-0006ZB-00 for xcon@ietf.org; Wed, 28 Jan 2004 09:40:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alqqz-0006UB-00 for xcon@ietf.org; Wed, 28 Jan 2004 09:39:43 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AlqqW-0006Ou-00 for xcon@ietf.org; Wed, 28 Jan 2004 09:39:13 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0SEZdPX002517 for ; Wed, 28 Jan 2004 09:35:39 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0SEZbPX002448 for ; Wed, 28 Jan 2004 09:35:37 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 28 Jan 2004 09:39:07 -0500 Message-ID: <8CA1128D59AD27429985B397118CEDDF0186BD9B@nj7460avexu1.global.avaya.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPjSbi3pMFvfOcVSTOgmgHpIc0jOQA90fOQAEvBJTAACJlw0AAGZ3Sw From: "Boyer, David G (Dave)" To: , , Cc: 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If a conference focus is created at conference start time by a = conference factory, the focus will only need to know it's end time in = order to prevent any users from joining. Repeat times and more complex reservations can be handled by an = "external" reservation application. Dave Boyer -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of hisham.khartabil@nokia.com Sent: Wednesday, January 28, 2004 6:50 AM To: eburger@snowshore.com; xcon@ietf.org Cc: roni.even@polycom.co.il Subject: RE: [XCON] CPCP Requirement: Repeat times=20 Let me elaborate a little on this proposal. I agree that eventually we need complex scheduling for conferences. We = can pick this up after we finalise a solution for CPCP. In can be = decided at that point if this scheduling could be done inside CPCP as an = extension (similar approach to CPL) or is a separate protocol. In the mean time, we can define a very simple start, stop and repeat = times that is OPTIONAL TO IMPLEMENT at the client side. The purpose of = those would not be to indicate the need for resource reservation, = although they can be used for that. Start time indicates to the focus when it should start allowing users to = join or when it should invite users to join. Stop time indicates to the focus when it should stop allowing users to = join. It also indicates that the focus should not invite users that have = been added to dial-out list. Repeat times is obvious. Again, this would be optional and can be deprecated by a more complex = scheduling solution. Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 28.January.2004 09:30 > To: eburger@snowshore.com; xcon@ietf.org > Cc: roni.even@polycom.co.il > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I'm sorry, but I don't buy the argument that just because=20 > scheduling is complex it requires a separate protocol.=20 > Henning did mention how they approached the problem for CPL.=20 > We can adopt that here also. >=20 > If we don't want a full scheduling solution yet, then we=20 > start with something basic and design the protocol in a way=20 > that allows complex scheduling to be added later. >=20 > /Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: 26.January.2004 21:23 > > To: xcon@ietf.org > > Cc: Even, Roni > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > I started to say that it was totally out of scope. Here are=20 > > both sides of the coin: > >=20 > > AGAINST *ANY* SCHEDULING IN CPCP: > > Scheduling logic is arbitrarily complex. Scheduling=20 > > semantics are arbitrarily complex, and have been tackled in=20 > > other venues much better than we every will (e.g., iCal). =20 > > What more does CPCP need other than "Create conference NOW"=20 > > and "Remove conference NOW"? > >=20 > > FOR *SOME* SCHEDULING IN CPCP: > > Resource management should be at the focus, not at the=20 > > application. This would lead to "Reserve resources for a=20 > > conference starting LATER" (could succeed or fail). > >=20 > > I *might* understand "Reserve resources for a conference that=20 > > repeats every {time unit}". > >=20 > > I would NOT approve "Reserve resources for a conference that=20 > > repeats every week except for the week after next." Limit=20 > > ourselves to "Reserve resources for a conference this week=20 > > and next. + Reserve resources for a conference starting=20 > > three weeks from now." > >=20 > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: Sunday, January 25, 2004 8:44 AM > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hi, > > > Repeating myself I would like to state my objection, and I=20 > > > would suggest to > > > have conference reservation functionality not in the scope of=20 > > > conference > > > policy but maybe as an application functionality that we may=20 > > > consider as a > > > different working item. > > > Roni > > >=20 > > > ************************************* > > > Roni Even > > >=20 > > > 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=20 > > [mailto:petri.koskelainen@nokia.com] > > > Sent: Sunday, January 25, 2004 3:31 PM > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > >=20 > > > Back to the original question in this thread: > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > > If so, then we need to add a requirement. > > >=20 > > > I guess we can close this open issue now as rough consensus=20 > > seems to=20 > > > be that such a requirement is needed (at least for the=20 > > > start/stop/repeat > > > times). > > > Note that we don't have to design the actual solution yet=20 > > > (e.g. using iCal vs defining own format). > > >=20 > > > -- > > > Petri > > >=20 > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 21.January.2004 16:09 > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > I think we need to figure out where we are going on=20 > scheduling. > > > > >=20 > > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > > least specify start/stop times for conferences, and that if=20 > > > > > the start time is in the future, that is a reservation. > > > >=20 > > > > Agreed. > > > >=20 > > > > >=20 > > > > > What I want to discuss is, how far do we go, and what is=20 > > > > the end game? > > > > > I think we can agree that generalized scheduling is complex,=20 > > > > > and standards exist (iCal). So, the issue I want to=20 > discuss is: > > > > > if we allow simple scheduling (start/stop) now,=20 > > do we EVENTUALLY > > > > > allow complex scheduling? That implies=20 > > duplicating > > > significant > > > > > parts of e.g. iCal. > > > > >=20 > > > > > We could consider an alternative - explicitly support an iCal=20 > > > > > (actually iMIP) transaction now. =20 > > > > >=20 > > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > > iMIP) now (or maybe as a minimum). =20 > > > > >=20 > > > > > Or we could pull in some or all of calsch > > > >=20 > > > > If there is an XML schema already defined that we can use,=20 > > > then it is > > > > possible to embed that in CPCP. If you look at the solution=20 > > > > we are proposing (using XCAP), each feature, like=20 > > > conference-time, has its > > > own=20 > > > > XML namespace. > > > > We can take the iCal XML namespace and just drop it in there. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > >=20 > > > > > Brian > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Yes. > > > > > >=20 > > > > > > We all have weekly meetings with predefined start and stop=20 > > > > > > times. I think it is a valid use case for a user to=20 > create a=20 > > > > > > conference policy to satisfy this once and once only. > > > > > >=20 > > > > > > Regards, > > > > > > Hisham > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > > Koskelainen Petri > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > For that matter, is there a use case for end=20 > points (XCON)=20 > > > > > > > doing such complicated scheduling? Why don't we=20 > just take=20 > > > > > > > the bridge out of service? > > > > > > >=20 > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > >=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hisham, > > > > > > > >=20 > > > > > > > > The conference server is not mentioned in > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > framework=20 > > > > > > > > mentioned the > > > > > > > > conference policy server. As for reservation my=20 > > > view is that=20 > > > > > > > > reservation is > > > > > > > > starting an ad-hoc conference when the schedule=20 > time has=20 > > > > > > > > arrived and it > > > > > > > > should not be part of the conference policy.=20 > > Reservation is=20 > > > > > > > a separate > > > > > > > > application from the conference policy. I=20 > suggest that if=20 > > > > > > > you want to > > > > > > > > address it then we should have a separate=20 > element in the=20 > > > > > > > > frame work which > > > > > > > > will be a reservation server. > > > > > > > >=20 > > > > > > > > Roni > > > > > > > >=20 > > > > > > > > ************************************* > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > Polycom Israel > > > > > > > >=20 > > > > > > > > Tel: +972-3-9251200 > > > > > > > > Cell: +972-55-481099 > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > ******************************************* > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > To: roni.even@polycom.co.il;=20 > petri.koskelainen@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > No, the focus host (conference server) is the one that=20 > > > > > handles the > > > > > > > > reservations. The focus is only created and=20 > > > destroyed by the=20 > > > > > > > > conference > > > > > > > > server according to the start and stop times. > > > > > > > >=20 > > > > > > > > /Hisham > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > Even, Roni;=20 > > > > > > > > > Khartabil Hisham > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi Petri, > > > > > > > > > The CPS is a data storage that is used by the=20 > > > focus, so the=20 > > > > > > > > > focus will have > > > > > > > > > to handle the reservation > > > > > > > > > Roni > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > To: roni.even@polycom.co.il;=20 > > hisham.khartabil@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > > Hi Roni, > > > > > > > > >=20 > > > > > > > > > > My opinion is that the conference policy=20 > needs only a=20 > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > application to the focus. According to the=20 > conference=20 > > > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > not the right place for reservation. > > > > > > > > >=20 > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > > capability in protocol since we need the feature anyway in=20 > > > real-world=20 > > > > (either in CPCP or in some new mystery protocol between the=20 > > > user and the=20 > > > > > > > reservation application). > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -- > > > > > > > > > Petri > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > Regards > > > > > > > > > > Roni Even > > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > To: xcon@ietf.org > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > > current proposed solution has repeat times (eg:=20 > > > meeting repeats > > > weekly),=20 > > > > > > > there is no requirement for such. > > > > > > > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > > so, then we need to add a requirement. > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Jan 29 10:02:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20445 for ; Thu, 29 Jan 2004 10:02:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDga-0007XT-4E for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:02:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TF2Si8028976 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDgZ-0007X7-T2 for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:02:27 -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 KAA20355 for ; Thu, 29 Jan 2004 10:02:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDgX-0006W2-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:02:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDfC-0006Al-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:01:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmDeF-0005yb-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDeF-0005jp-48; Thu, 29 Jan 2004 10:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDdd-0005cw-EZ for xcon@optimus.ietf.org; Thu, 29 Jan 2004 09:59:25 -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 JAA20134 for ; Thu, 29 Jan 2004 09:59:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDdb-0005wb-00 for xcon@ietf.org; Thu, 29 Jan 2004 09:59:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDcd-0005r2-00 for xcon@ietf.org; Thu, 29 Jan 2004 09:58:24 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AmDcJ-0005kz-00 for xcon@ietf.org; Thu, 29 Jan 2004 09:58:04 -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.0) with ESMTP id i0TEvTZ13226 for ; Thu, 29 Jan 2004 08:57:29 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 14:57:24 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AF4C5B1@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Henning Schulzrinne , hisham.khartabil@nokia.com Cc: xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 14:57:22 -0000 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=none autolearn=no version=2.60 I am not convinced we need the repeat times either. That is surely something that can be dealt with by some other application which then uses CPCP. regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 28 January 2004 13:30 > To: hisham.khartabil@nokia.com > Cc: eburger@snowshore.com; xcon@ietf.org; roni.even@polycom.co.il > Subject: Re: [XCON] CPCP Requirement: Repeat times > > > > If we don't want a full scheduling solution yet, then we start with > > something basic and design the protocol in a way that allows complex > > scheduling to be added later. > > It's unclear to me what value repeat times add. They are just an > abbreviation for having several instances. Repeat times make > sense for a > human user, but CPCP is likely at least one layer of > indirection removed > from a GUI. The problem with repeat times is that things get messy > quickly, even for the seemingly trivial cases. Random example: > conference repeats once a week at 9 am. However, daylight > savings time > happens during the repeats. If you just repeat every 86400*7 seconds, > suddenly your conference starts an hour earlier or later than you had > planned on. Thus, you now need to make sure you encode timezones > correctly, plus making the implementation messier and more > error-prone, > for no additional functional capability that couldn't have been > expressed by just enumerating the instances. > > _______________________________________________ > 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 Jan 29 10:09:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21842 for ; Thu, 29 Jan 2004 10:09:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDnP-0001xr-4B for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:09:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TF9VGd007545 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:09:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDnO-0001xc-VG for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:09:31 -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 KAA21741 for ; Thu, 29 Jan 2004 10:09:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDnN-0000OU-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:09:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDmW-0000Af-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:08:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmDkz-0007YJ-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDl1-0000w5-8U; Thu, 29 Jan 2004 10:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDkc-0000mw-3N for xcon@optimus.ietf.org; Thu, 29 Jan 2004 10:06:38 -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 KAA21071 for ; Thu, 29 Jan 2004 10:06:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDkZ-0007TE-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:06:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDic-00070n-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:04:35 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly02a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AmDhK-0006aW-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:03:14 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02a.srv.mailcontrol.com (MailControl) with SMTP id i0TF2NZI020169; Thu, 29 Jan 2004 15:02:23 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 29 Jan 2004 15:02:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 15:02:22 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF136@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPmeJYXVR4oDr30Q0aFKI0fXuse9AAADmlw From: "Chris Boulton" To: "Drage, Keith (Keith)" , "Henning Schulzrinne" , Cc: X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm also not convinced that this is a requirement. Chris. >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com] >Sent: 29 January 2004 14:57 >To: Henning Schulzrinne; hisham.khartabil@nokia.com >Cc: xcon@ietf.org >Subject: RE: [XCON] CPCP Requirement: Repeat times > >I am not convinced we need the repeat times either. > >That is surely something that can be dealt with by some other application >which then uses CPCP. > >regards > >Keith > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: 28 January 2004 13:30 >> To: hisham.khartabil@nokia.com >> Cc: eburger@snowshore.com; xcon@ietf.org; roni.even@polycom.co.il >> Subject: Re: [XCON] CPCP Requirement: Repeat times >> >> >> > If we don't want a full scheduling solution yet, then we start with >> > something basic and design the protocol in a way that allows complex >> > scheduling to be added later. >> >> It's unclear to me what value repeat times add. They are just an >> abbreviation for having several instances. Repeat times make >> sense for a >> human user, but CPCP is likely at least one layer of >> indirection removed >> from a GUI. The problem with repeat times is that things get messy >> quickly, even for the seemingly trivial cases. Random example: >> conference repeats once a week at 9 am. However, daylight >> savings time >> happens during the repeats. If you just repeat every 86400*7 seconds, >> suddenly your conference starts an hour earlier or later than you had >> planned on. Thus, you now need to make sure you encode timezones >> correctly, plus making the implementation messier and more >> error-prone, >> for no additional functional capability that couldn't have been >> expressed by just enumerating the instances. >> >> _______________________________________________ >> 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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Jan 29 10:27:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24296 for ; Thu, 29 Jan 2004 10:27: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 1AmE4j-0007i9-5z for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:27:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFRP1s029639 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE4j-0007hy-0O for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:27:25 -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 KAA24269 for ; Thu, 29 Jan 2004 10:27:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmE4g-0002rP-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:27:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmE3u-0002lb-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:26:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmE3L-0002ep-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:25:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE3N-0007O7-3E; Thu, 29 Jan 2004 10:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE2q-0007DL-3W for xcon@optimus.ietf.org; Thu, 29 Jan 2004 10:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24175 for ; Thu, 29 Jan 2004 10:25:24 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmE2n-0002c7-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmE23-0002WH-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:24:40 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AmE1N-0002PE-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:23:58 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0TFNuM28771 for ; Thu, 29 Jan 2004 17:23:56 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 17:23:54 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 17:23:54 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 17:23:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 17:23:53 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0CB3@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPmeJYXVR4oDr30Q0aFKI0fXuse9AAADmlwAAC0I7A= To: , , , Cc: X-OriginalArrivalTime: 29 Jan 2004 15:23:53.0829 (UTC) FILETIME=[E7A60950:01C3E67B] 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Agreed. I'll submit new version shortly including requirements only for = start/stop times. Petri > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Chris Boulton > Sent: 29 January, 2004 17:02 > To: Drage, Keith (Keith); Henning Schulzrinne; Khartabil Hisham > (Nokia-TP/Helsinki) > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times >=20 >=20 > I'm also not convinced that this is a requirement. >=20 > Chris. >=20 >=20 > >-----Original Message----- > >From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >Sent: 29 January 2004 14:57 > >To: Henning Schulzrinne; hisham.khartabil@nokia.com > >Cc: xcon@ietf.org > >Subject: RE: [XCON] CPCP Requirement: Repeat times > > > >I am not convinced we need the repeat times either. > > > >That is surely something that can be dealt with by some other > application > >which then uses CPCP. > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: 28 January 2004 13:30 > >> To: hisham.khartabil@nokia.com > >> Cc: eburger@snowshore.com; xcon@ietf.org; roni.even@polycom.co.il > >> Subject: Re: [XCON] CPCP Requirement: Repeat times > >> > >> > >> > If we don't want a full scheduling solution yet, then we=20 > start with > >> > something basic and design the protocol in a way that allows > complex > >> > scheduling to be added later. > >> > >> It's unclear to me what value repeat times add. They are just an > >> abbreviation for having several instances. Repeat times make > >> sense for a > >> human user, but CPCP is likely at least one layer of > >> indirection removed > >> from a GUI. The problem with repeat times is that things get messy > >> quickly, even for the seemingly trivial cases. Random example: > >> conference repeats once a week at 9 am. However, daylight > >> savings time > >> happens during the repeats. If you just repeat every=20 > 86400*7 seconds, > >> suddenly your conference starts an hour earlier or later=20 > than you had > >> planned on. Thus, you now need to make sure you encode timezones > >> correctly, plus making the implementation messier and more > >> error-prone, > >> for no additional functional capability that couldn't have been > >> expressed by just enumerating the instances. > >> > >> _______________________________________________ > >> 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 > This message has been scanned for viruses by MailControl -=20 www.mailcontrol.com _______________________________________________ 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 Jan 29 10:50:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27126 for ; Thu, 29 Jan 2004 10:50:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEQt-0000du-Hv for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:50:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFoJVl002464 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEQt-0000df-C2 for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:50:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26989 for ; Thu, 29 Jan 2004 10:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEQq-00079T-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEPN-0006pk-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:48:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmENe-0006MY-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmENg-0000Qx-At; Thu, 29 Jan 2004 10:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmENW-0000Qc-Ni for xcon@optimus.ietf.org; Thu, 29 Jan 2004 10:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26352 for ; Thu, 29 Jan 2004 10:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmENU-0006KR-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmELd-0005qD-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:44:57 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AmEJK-00054r-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:42:31 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 20372; Thu, 29 Jan 2004 10:43:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 10:41:50 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A0C4@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPjSbi3pMFvfOcVSTOgmgHpIc0jOQA90fOQAEvBJTAACJlw0AAGZ3SwADMGh/A= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Exactly. The idea "we'll start small and extend later" on the = reservation / scheduling function is how we will end up re-inventing = iCal, only this time with people with less expertise in the area... I think all we need is start time & end time. Period. > -----Original Message----- > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com] > Sent: Wednesday, January 28, 2004 9:39 AM > To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > Cc: roni.even@polycom.co.il > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > If a conference focus is created at conference start time by=20 > a conference factory, the focus will only need to know it's=20 > end time in order to prevent any users from joining. > Repeat times and more complex reservations can be handled by=20 > an "external" reservation > application. >=20 > Dave Boyer > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of > hisham.khartabil@nokia.com > Sent: Wednesday, January 28, 2004 6:50 AM > To: eburger@snowshore.com; xcon@ietf.org > Cc: roni.even@polycom.co.il > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Let me elaborate a little on this proposal. >=20 > I agree that eventually we need complex scheduling for=20 > conferences. We can pick this up after we finalise a solution=20 > for CPCP. In can be decided at that point if this scheduling=20 > could be done inside CPCP as an extension (similar approach=20 > to CPL) or is a separate protocol. >=20 > In the mean time, we can define a very simple start, stop and=20 > repeat times that is OPTIONAL TO IMPLEMENT at the client=20 > side. The purpose of those would not be to indicate the need=20 > for resource reservation, although they can be used for that. >=20 > Start time indicates to the focus when it should start=20 > allowing users to join or when it should invite users to join. > Stop time indicates to the focus when it should stop allowing=20 > users to join. It also indicates that the focus should not=20 > invite users that have been added to dial-out list. > Repeat times is obvious. >=20 > Again, this would be optional and can be deprecated by a more=20 > complex scheduling solution. >=20 > Regards, > Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > hisham.khartabil@nokia.com > > Sent: 28.January.2004 09:30 > > To: eburger@snowshore.com; xcon@ietf.org > > Cc: roni.even@polycom.co.il > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > I'm sorry, but I don't buy the argument that just because=20 > > scheduling is complex it requires a separate protocol.=20 > > Henning did mention how they approached the problem for CPL.=20 > > We can adopt that here also. > >=20 > > If we don't want a full scheduling solution yet, then we=20 > > start with something basic and design the protocol in a way=20 > > that allows complex scheduling to be added later. > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Eric Burger > > > Sent: 26.January.2004 21:23 > > > To: xcon@ietf.org > > > Cc: Even, Roni > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > I started to say that it was totally out of scope. Here are=20 > > > both sides of the coin: > > >=20 > > > AGAINST *ANY* SCHEDULING IN CPCP: > > > Scheduling logic is arbitrarily complex. Scheduling=20 > > > semantics are arbitrarily complex, and have been tackled in=20 > > > other venues much better than we every will (e.g., iCal). =20 > > > What more does CPCP need other than "Create conference NOW"=20 > > > and "Remove conference NOW"? > > >=20 > > > FOR *SOME* SCHEDULING IN CPCP: > > > Resource management should be at the focus, not at the=20 > > > application. This would lead to "Reserve resources for a=20 > > > conference starting LATER" (could succeed or fail). > > >=20 > > > I *might* understand "Reserve resources for a conference that=20 > > > repeats every {time unit}". > > >=20 > > > I would NOT approve "Reserve resources for a conference that=20 > > > repeats every week except for the week after next." Limit=20 > > > ourselves to "Reserve resources for a conference this week=20 > > > and next. + Reserve resources for a conference starting=20 > > > three weeks from now." > > >=20 > > > > -----Original Message----- > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: Sunday, January 25, 2004 8:44 AM > > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > Hi, > > > > Repeating myself I would like to state my objection, and I=20 > > > > would suggest to > > > > have conference reservation functionality not in the scope of=20 > > > > conference > > > > policy but maybe as an application functionality that we may=20 > > > > consider as a > > > > different working item. > > > > Roni > > > >=20 > > > > ************************************* > > > > Roni Even > > > >=20 > > > > 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=20 > > > [mailto:petri.koskelainen@nokia.com] > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > To: xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > >=20 > > > > Back to the original question in this thread: > > > >=20 > > > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > > > If so, then we need to add a requirement. > > > >=20 > > > > I guess we can close this open issue now as rough consensus=20 > > > seems to=20 > > > > be that such a requirement is needed (at least for the=20 > > > > start/stop/repeat > > > > times). > > > > Note that we don't have to design the actual solution yet=20 > > > > (e.g. using iCal vs defining own format). > > > >=20 > > > > -- > > > > Petri > > > >=20 > > > > > > -----Original Message----- > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: 21.January.2004 16:09 > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > I think we need to figure out where we are going on=20 > > scheduling. > > > > > >=20 > > > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > > > least specify start/stop times for conferences, and that if=20 > > > > > > the start time is in the future, that is a reservation. > > > > >=20 > > > > > Agreed. > > > > >=20 > > > > > >=20 > > > > > > What I want to discuss is, how far do we go, and what is=20 > > > > > the end game? > > > > > > I think we can agree that generalized scheduling is=20 > complex,=20 > > > > > > and standards exist (iCal). So, the issue I want to=20 > > discuss is: > > > > > > if we allow simple scheduling (start/stop) now,=20 > > > do we EVENTUALLY > > > > > > allow complex scheduling? That implies=20 > > > duplicating > > > > significant > > > > > > parts of e.g. iCal. > > > > > >=20 > > > > > > We could consider an alternative - explicitly=20 > support an iCal=20 > > > > > > (actually iMIP) transaction now. =20 > > > > > >=20 > > > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > > > iMIP) now (or maybe as a minimum). =20 > > > > > >=20 > > > > > > Or we could pull in some or all of calsch > > > > >=20 > > > > > If there is an XML schema already defined that we can use,=20 > > > > then it is > > > > > possible to embed that in CPCP. If you look at the solution=20 > > > > > we are proposing (using XCAP), each feature, like=20 > > > > conference-time, has its > > > > own=20 > > > > > XML namespace. > > > > > We can take the iCal XML namespace and just drop it in there. > > > > >=20 > > > > > Regards, > > > > > Hisham > > > > >=20 > > > > > >=20 > > > > > > Brian > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Yes. > > > > > > >=20 > > > > > > > We all have weekly meetings with predefined start=20 > and stop=20 > > > > > > > times. I think it is a valid use case for a user to=20 > > create a=20 > > > > > > > conference policy to satisfy this once and once only. > > > > > > >=20 > > > > > > > Regards, > > > > > > > Hisham > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > > > Koskelainen Petri > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > For that matter, is there a use case for end=20 > > points (XCON)=20 > > > > > > > > doing such complicated scheduling? Why don't we=20 > > just take=20 > > > > > > > > the bridge out of service? > > > > > > > >=20 > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hisham, > > > > > > > > >=20 > > > > > > > > > The conference server is not mentioned in > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > > framework=20 > > > > > > > > > mentioned the > > > > > > > > > conference policy server. As for reservation my=20 > > > > view is that=20 > > > > > > > > > reservation is > > > > > > > > > starting an ad-hoc conference when the schedule=20 > > time has=20 > > > > > > > > > arrived and it > > > > > > > > > should not be part of the conference policy.=20 > > > Reservation is=20 > > > > > > > > a separate > > > > > > > > > application from the conference policy. I=20 > > suggest that if=20 > > > > > > > > you want to > > > > > > > > > address it then we should have a separate=20 > > element in the=20 > > > > > > > > > frame work which > > > > > > > > > will be a reservation server. > > > > > > > > >=20 > > > > > > > > > Roni > > > > > > > > >=20 > > > > > > > > > ************************************* > > > > > > > > > Roni Even > > > > > > > > >=20 > > > > > > > > > Polycom Israel > > > > > > > > >=20 > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > ******************************************* > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > To: roni.even@polycom.co.il;=20 > > petri.koskelainen@nokia.com;=20 > > > > > > > > > xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > No, the focus host (conference server) is the=20 > one that=20 > > > > > > handles the > > > > > > > > > reservations. The focus is only created and=20 > > > > destroyed by the=20 > > > > > > > > > conference > > > > > > > > > server according to the start and stop times. > > > > > > > > >=20 > > > > > > > > > /Hisham > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Even, Roni=20 > [mailto:roni.even@polycom.co.il] > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > > Even, Roni;=20 > > > > > > > > > > Khartabil Hisham > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > Hi Petri, > > > > > > > > > > The CPS is a data storage that is used by the=20 > > > > focus, so the=20 > > > > > > > > > > focus will have > > > > > > > > > > to handle the reservation > > > > > > > > > > Roni > > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > To: roni.even@polycom.co.il;=20 > > > hisham.khartabil@nokia.com;=20 > > > > > > > > > xcon@ietf.org > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > > >=20 > > > > > > > > > > Hi Roni, > > > > > > > > > >=20 > > > > > > > > > > > My opinion is that the conference policy=20 > > needs only a=20 > > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > > application to the focus. According to the=20 > > conference=20 > > > > > > > > > > > framework the focus is using the=20 > information in the=20 > > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > > not the right place for reservation. > > > > > > > > > >=20 > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > > > capability in protocol since we need the feature anyway in=20 > > > > real-world=20 > > > > > (either in CPCP or in some new mystery protocol between the=20 > > > > user and the=20 > > > > > > > > reservation application). > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > -- > > > > > > > > > > Petri > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > > Regards > > > > > > > > > > > Roni Even > > > > > > > > > > >=20 > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > > > current proposed solution has repeat times (eg:=20 > > > > meeting repeats > > > > weekly),=20 > > > > > > > > there is no requirement for such. > > > > > > > > > >=20 > > > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > > > so, then we need to add a requirement. > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Jan 29 10:55:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27814 for ; Thu, 29 Jan 2004 10:55:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEV9-0000ty-SN for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:54:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFshZr003459 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 10:54:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEV9-0000th-Md for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:54:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27735 for ; Thu, 29 Jan 2004 10:54:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEV7-0000Pn-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:54:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEU9-0000Al-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:53:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AmESY-0007YY-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:52:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AmESY-0006sy-Ml for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmESX-0000kB-6O; Thu, 29 Jan 2004 10:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmERz-0000gU-3K for xcon@optimus.ietf.org; Thu, 29 Jan 2004 10:51:27 -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 KAA27233 for ; Thu, 29 Jan 2004 10:51:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmERw-0007Rm-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:51:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmER2-0007Fn-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:50:32 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AmEPi-0006nq-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:49:06 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jan 2004 10:48:22 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6355@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eric Burger'" , hisham.khartabil@nokia.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 10:48:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Do we all agree that the start time can be in the future, and that constitutes a (simple) reservation? I am also okay with no repeats. Brian > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, January 29, 2004 10:42 AM > To: hisham.khartabil@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Exactly. The idea "we'll start small and extend later" on > the reservation / scheduling function is how we will end up > re-inventing iCal, only this time with people with less > expertise in the area... > > I think all we need is start time & end time. Period. > > > -----Original Message----- > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com] > > Sent: Wednesday, January 28, 2004 9:39 AM > > To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > > Cc: roni.even@polycom.co.il > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > If a conference focus is created at conference start time by > > a conference factory, the focus will only need to know it's > > end time in order to prevent any users from joining. > > Repeat times and more complex reservations can be handled by > > an "external" reservation > > application. > > > > Dave Boyer > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of > > hisham.khartabil@nokia.com > > Sent: Wednesday, January 28, 2004 6:50 AM > > To: eburger@snowshore.com; xcon@ietf.org > > Cc: roni.even@polycom.co.il > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Let me elaborate a little on this proposal. > > > > I agree that eventually we need complex scheduling for > > conferences. We can pick this up after we finalise a solution > > for CPCP. In can be decided at that point if this scheduling > > could be done inside CPCP as an extension (similar approach > > to CPL) or is a separate protocol. > > > > In the mean time, we can define a very simple start, stop and > > repeat times that is OPTIONAL TO IMPLEMENT at the client > > side. The purpose of those would not be to indicate the need > > for resource reservation, although they can be used for that. > > > > Start time indicates to the focus when it should start > > allowing users to join or when it should invite users to join. > > Stop time indicates to the focus when it should stop allowing > > users to join. It also indicates that the focus should not > > invite users that have been added to dial-out list. > > Repeat times is obvious. > > > > Again, this would be optional and can be deprecated by a more > > complex scheduling solution. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > Behalf Of ext > > > hisham.khartabil@nokia.com > > > Sent: 28.January.2004 09:30 > > > To: eburger@snowshore.com; xcon@ietf.org > > > Cc: roni.even@polycom.co.il > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > I'm sorry, but I don't buy the argument that just because > > > scheduling is complex it requires a separate protocol. > > > Henning did mention how they approached the problem for CPL. > > > We can adopt that here also. > > > > > > If we don't want a full scheduling solution yet, then we > > > start with something basic and design the protocol in a way > > > that allows complex scheduling to be added later. > > > > > > /Hisham > > > > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > Behalf Of ext > > > > Eric Burger > > > > Sent: 26.January.2004 21:23 > > > > To: xcon@ietf.org > > > > Cc: Even, Roni > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > I started to say that it was totally out of scope. Here are > > > > both sides of the coin: > > > > > > > > AGAINST *ANY* SCHEDULING IN CPCP: > > > > Scheduling logic is arbitrarily complex. Scheduling > > > > semantics are arbitrarily complex, and have been tackled in > > > > other venues much better than we every will (e.g., iCal). > > > > What more does CPCP need other than "Create conference NOW" > > > > and "Remove conference NOW"? > > > > > > > > FOR *SOME* SCHEDULING IN CPCP: > > > > Resource management should be at the focus, not at the > > > > application. This would lead to "Reserve resources for a > > > > conference starting LATER" (could succeed or fail). > > > > > > > > I *might* understand "Reserve resources for a conference that > > > > repeats every {time unit}". > > > > > > > > I would NOT approve "Reserve resources for a conference that > > > > repeats every week except for the week after next." Limit > > > > ourselves to "Reserve resources for a conference this week > > > > and next. + Reserve resources for a conference starting > > > > three weeks from now." > > > > > > > > > -----Original Message----- > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > Sent: Sunday, January 25, 2004 8:44 AM > > > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > Hi, > > > > > Repeating myself I would like to state my objection, and I > > > > > would suggest to > > > > > have conference reservation functionality not in the scope of > > > > > conference > > > > > policy but maybe as an application functionality that we may > > > > > consider as a > > > > > different working item. > > > > > Roni > > > > > > > > > > ************************************* > > > > > Roni Even > > > > > > > > > > Polycom Israel > > > > > > > > > > Tel: +972-3-9251200 > > > > > Cell: +972-55-481099 > > > > > email:roni.even@polycom.co.il > > > > > ******************************************* > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: petri.koskelainen@nokia.com > > > > [mailto:petri.koskelainen@nokia.com] > > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > > To: xcon@ietf.org > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > Back to the original question in this thread: > > > > > > > > > > > > > > > > Do we see a need for such capability using CPCP? > > > > > > > > > > > If so, then we need to add a requirement. > > > > > > > > > > I guess we can close this open issue now as rough consensus > > > > seems to > > > > > be that such a requirement is needed (at least for the > > > > > start/stop/repeat > > > > > times). > > > > > Note that we don't have to design the actual solution yet > > > > > (e.g. using iCal vs defining own format). > > > > > > > > > > -- > > > > > Petri > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > Sent: 21.January.2004 16:09 > > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > I think we need to figure out where we are going on > > > scheduling. > > > > > > > > > > > > > > First, let me say that I think we SHOULD allow CPCP to at > > > > > > > least specify start/stop times for conferences, > and that if > > > > > > > the start time is in the future, that is a reservation. > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > What I want to discuss is, how far do we go, and what is > > > > > > the end game? > > > > > > > I think we can agree that generalized scheduling is > > complex, > > > > > > > and standards exist (iCal). So, the issue I want to > > > discuss is: > > > > > > > if we allow simple scheduling (start/stop) now, > > > > do we EVENTUALLY > > > > > > > allow complex scheduling? That implies > > > > duplicating > > > > > significant > > > > > > > parts of e.g. iCal. > > > > > > > > > > > > > > We could consider an alternative - explicitly > > support an iCal > > > > > > > (actually iMIP) transaction now. > > > > > > > > > > > > > > One could allow the iMIP Request/Reply only (ie subset of > > > > > > > iMIP) now (or maybe as a minimum). > > > > > > > > > > > > > > Or we could pull in some or all of calsch > > > > > > > > > > > > If there is an XML schema already defined that we can use, > > > > > then it is > > > > > > possible to embed that in CPCP. If you look at the solution > > > > > > we are proposing (using XCAP), each feature, like > > > > > conference-time, has its > > > > > own > > > > > > XML namespace. > > > > > > We can take the iCal XML namespace and just drop it > in there. > > > > > > > > > > > > Regards, > > > > > > Hisham > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > We all have weekly meetings with predefined start > > and stop > > > > > > > > times. I think it is a valid use case for a user to > > > create a > > > > > > > > conference policy to satisfy this once and once only. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Hisham > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > > > > > > Koskelainen Petri > > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > For that matter, is there a use case for end > > > points (XCON) > > > > > > > > > doing such complicated scheduling? Why don't we > > > just take > > > > > > > > > the bridge out of service? > > > > > > > > > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > > > > > > > > > The conference server is not mentioned in > > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The > > > > framework > > > > > > > > > > mentioned the > > > > > > > > > > conference policy server. As for reservation my > > > > > view is that > > > > > > > > > > reservation is > > > > > > > > > > starting an ad-hoc conference when the schedule > > > time has > > > > > > > > > > arrived and it > > > > > > > > > > should not be part of the conference policy. > > > > Reservation is > > > > > > > > > a separate > > > > > > > > > > application from the conference policy. I > > > suggest that if > > > > > > > > > you want to > > > > > > > > > > address it then we should have a separate > > > element in the > > > > > > > > > > frame work which > > > > > > > > > > will be a reservation server. > > > > > > > > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > ************************************* > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > > To: roni.even@polycom.co.il; > > > petri.koskelainen@nokia.com; > > > > > > > > > > xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the > > one that > > > > > > > handles the > > > > > > > > > > reservations. The focus is only created and > > > > > destroyed by the > > > > > > > > > > conference > > > > > > > > > > server according to the start and stop times. > > > > > > > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Even, Roni > > [mailto:roni.even@polycom.co.il] > > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); > > > Even, Roni; > > > > > > > > > > > Khartabil Hisham > > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > > > > > The CPS is a data storage that is used by the > > > > > focus, so the > > > > > > > > > > > focus will have > > > > > > > > > > > to handle the reservation > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > > To: roni.even@polycom.co.il; > > > > hisham.khartabil@nokia.com; > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > Repeat times > > > > > > > > > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > > > > > > > > > My opinion is that the conference policy > > > needs only a > > > > > > > > > > > > conference duration parameter if any. > > > > > > > > > > > > I think that reservation is an external > > > > > > > > > > > > application to the focus. According to the > > > conference > > > > > > > > > > > > framework the focus is using the > > information in the > > > > > > > > > > > > conference policy server and the focus is > > > > > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > > I think it makes sense to have this (repeat time) > > > > > > capability in protocol since we need the feature anyway in > > > > > real-world > > > > > > (either in CPCP or in some new mystery protocol between the > > > > > user and the > > > > > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. > Although the > > > > > > > > > current proposed solution has repeat times (eg: > > > > > meeting repeats > > > > > weekly), > > > > > > > > > there is no requirement for such. > > > > > > > > > > > > > > > > > > > > > > Do we see a need for such capability > using CPCP? If > > > > > > so, then we need to add a requirement. > > > > > > > > > > _______________________________________________ > > > > > 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 From exim@www1.ietf.org Thu Jan 29 11:01:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28309 for ; Thu, 29 Jan 2004 11:01:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEas-0001Dl-1Q for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 11:00:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TG0ai2004686 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 11:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEap-0001DT-M6 for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 11:00:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28305 for ; Thu, 29 Jan 2004 11:00:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEam-0001JV-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 11:00:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEZq-0001Cy-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:59:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AmEZJ-000160-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:59:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AmEZJ-0007QQ-CQ for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 10:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEZI-000195-IZ; Thu, 29 Jan 2004 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEYm-00017r-Ah for xcon@optimus.ietf.org; Thu, 29 Jan 2004 10:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28201 for ; Thu, 29 Jan 2004 10:58:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEYj-00014c-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEXs-0000xc-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:57:34 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AmEXI-0000m9-00 for xcon@ietf.org; Thu, 29 Jan 2004 10:56:56 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 20394; Thu, 29 Jan 2004 10:58:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 10:56:23 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A0CB@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPmf1ziF8QAUNaaQPe0GwVrCFg5mAAAFcEg From: "Eric Burger" To: "Rosen, Brian" , 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If the start time is not in the future, it makes for a pretty useless = service :-) I can go for that. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, January 29, 2004 10:48 AM > To: Eric Burger; hisham.khartabil@nokia.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Do we all agree that the start time can be in the future, and that > constitutes a (simple) reservation? >=20 > I am also okay with no repeats. >=20 > Brian >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Thursday, January 29, 2004 10:42 AM > > To: hisham.khartabil@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Exactly. The idea "we'll start small and extend later" on=20 > > the reservation / scheduling function is how we will end up=20 > > re-inventing iCal, only this time with people with less=20 > > expertise in the area... > >=20 > > I think all we need is start time & end time. Period. > >=20 > > > -----Original Message----- > > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com] > > > Sent: Wednesday, January 28, 2004 9:39 AM > > > To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > > > Cc: roni.even@polycom.co.il > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > If a conference focus is created at conference start time by=20 > > > a conference factory, the focus will only need to know it's=20 > > > end time in order to prevent any users from joining. > > > Repeat times and more complex reservations can be handled by=20 > > > an "external" reservation > > > application. > > >=20 > > > Dave Boyer > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of > > > hisham.khartabil@nokia.com > > > Sent: Wednesday, January 28, 2004 6:50 AM > > > To: eburger@snowshore.com; xcon@ietf.org > > > Cc: roni.even@polycom.co.il > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Let me elaborate a little on this proposal. > > >=20 > > > I agree that eventually we need complex scheduling for=20 > > > conferences. We can pick this up after we finalise a solution=20 > > > for CPCP. In can be decided at that point if this scheduling=20 > > > could be done inside CPCP as an extension (similar approach=20 > > > to CPL) or is a separate protocol. > > >=20 > > > In the mean time, we can define a very simple start, stop and=20 > > > repeat times that is OPTIONAL TO IMPLEMENT at the client=20 > > > side. The purpose of those would not be to indicate the need=20 > > > for resource reservation, although they can be used for that. > > >=20 > > > Start time indicates to the focus when it should start=20 > > > allowing users to join or when it should invite users to join. > > > Stop time indicates to the focus when it should stop allowing=20 > > > users to join. It also indicates that the focus should not=20 > > > invite users that have been added to dial-out list. > > > Repeat times is obvious. > > >=20 > > > Again, this would be optional and can be deprecated by a more=20 > > > complex scheduling solution. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > hisham.khartabil@nokia.com > > > > Sent: 28.January.2004 09:30 > > > > To: eburger@snowshore.com; xcon@ietf.org > > > > Cc: roni.even@polycom.co.il > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > I'm sorry, but I don't buy the argument that just because=20 > > > > scheduling is complex it requires a separate protocol.=20 > > > > Henning did mention how they approached the problem for CPL.=20 > > > > We can adopt that here also. > > > >=20 > > > > If we don't want a full scheduling solution yet, then we=20 > > > > start with something basic and design the protocol in a way=20 > > > > that allows complex scheduling to be added later. > > > >=20 > > > > /Hisham > > > >=20 > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > Behalf Of ext > > > > > Eric Burger > > > > > Sent: 26.January.2004 21:23 > > > > > To: xcon@ietf.org > > > > > Cc: Even, Roni > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > I started to say that it was totally out of scope. Here are=20 > > > > > both sides of the coin: > > > > >=20 > > > > > AGAINST *ANY* SCHEDULING IN CPCP: > > > > > Scheduling logic is arbitrarily complex. Scheduling=20 > > > > > semantics are arbitrarily complex, and have been tackled in=20 > > > > > other venues much better than we every will (e.g., iCal). =20 > > > > > What more does CPCP need other than "Create conference NOW"=20 > > > > > and "Remove conference NOW"? > > > > >=20 > > > > > FOR *SOME* SCHEDULING IN CPCP: > > > > > Resource management should be at the focus, not at the=20 > > > > > application. This would lead to "Reserve resources for a=20 > > > > > conference starting LATER" (could succeed or fail). > > > > >=20 > > > > > I *might* understand "Reserve resources for a conference that=20 > > > > > repeats every {time unit}". > > > > >=20 > > > > > I would NOT approve "Reserve resources for a conference that=20 > > > > > repeats every week except for the week after next." Limit=20 > > > > > ourselves to "Reserve resources for a conference this week=20 > > > > > and next. + Reserve resources for a conference starting=20 > > > > > three weeks from now." > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: Sunday, January 25, 2004 8:44 AM > > > > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Hi, > > > > > > Repeating myself I would like to state my objection, and I=20 > > > > > > would suggest to > > > > > > have conference reservation functionality not in=20 > the scope of=20 > > > > > > conference > > > > > > policy but maybe as an application functionality=20 > that we may=20 > > > > > > consider as a > > > > > > different working item. > > > > > > Roni > > > > > >=20 > > > > > > ************************************* > > > > > > Roni Even > > > > > >=20 > > > > > > 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=20 > > > > > [mailto:petri.koskelainen@nokia.com] > > > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > > > To: xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Back to the original question in this thread: > > > > > >=20 > > > > > > > > > > > > Do we see a need for such capability=20 > using CPCP?=20 > > > > > > > > > > > > If so, then we need to add a requirement. > > > > > >=20 > > > > > > I guess we can close this open issue now as rough consensus=20 > > > > > seems to=20 > > > > > > be that such a requirement is needed (at least for the=20 > > > > > > start/stop/repeat > > > > > > times). > > > > > > Note that we don't have to design the actual solution yet=20 > > > > > > (e.g. using iCal vs defining own format). > > > > > >=20 > > > > > > -- > > > > > > Petri > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > > Sent: 21.January.2004 16:09 > > > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > I think we need to figure out where we are going on=20 > > > > scheduling. > > > > > > > >=20 > > > > > > > > First, let me say that I think we SHOULD allow=20 > CPCP to at=20 > > > > > > > > least specify start/stop times for conferences,=20 > > and that if=20 > > > > > > > > the start time is in the future, that is a reservation. > > > > > > >=20 > > > > > > > Agreed. > > > > > > >=20 > > > > > > > >=20 > > > > > > > > What I want to discuss is, how far do we go,=20 > and what is=20 > > > > > > > the end game? > > > > > > > > I think we can agree that generalized scheduling is=20 > > > complex,=20 > > > > > > > > and standards exist (iCal). So, the issue I want to=20 > > > > discuss is: > > > > > > > > if we allow simple scheduling (start/stop) now,=20 > > > > > do we EVENTUALLY > > > > > > > > allow complex scheduling? That implies=20 > > > > > duplicating > > > > > > significant > > > > > > > > parts of e.g. iCal. > > > > > > > >=20 > > > > > > > > We could consider an alternative - explicitly=20 > > > support an iCal=20 > > > > > > > > (actually iMIP) transaction now. =20 > > > > > > > >=20 > > > > > > > > One could allow the iMIP Request/Reply only (ie=20 > subset of=20 > > > > > > > > iMIP) now (or maybe as a minimum). =20 > > > > > > > >=20 > > > > > > > > Or we could pull in some or all of calsch > > > > > > >=20 > > > > > > > If there is an XML schema already defined that we=20 > can use,=20 > > > > > > then it is > > > > > > > possible to embed that in CPCP. If you look at=20 > the solution=20 > > > > > > > we are proposing (using XCAP), each feature, like=20 > > > > > > conference-time, has its > > > > > > own=20 > > > > > > > XML namespace. > > > > > > > We can take the iCal XML namespace and just drop it=20 > > in there. > > > > > > >=20 > > > > > > > Regards, > > > > > > > Hisham > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Brian > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Yes. > > > > > > > > >=20 > > > > > > > > > We all have weekly meetings with predefined start=20 > > > and stop=20 > > > > > > > > > times. I think it is a valid use case for a user to=20 > > > > create a=20 > > > > > > > > > conference policy to satisfy this once and once only. > > > > > > > > >=20 > > > > > > > > > Regards, > > > > > > > > > Hisham > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > > > To: Even, Roni; Khartabil Hisham=20 > (Nokia-TP/Helsinki);=20 > > > > > > > > > > Koskelainen Petri > > > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > For that matter, is there a use case for end=20 > > > > points (XCON)=20 > > > > > > > > > > doing such complicated scheduling? Why don't we=20 > > > > just take=20 > > > > > > > > > > the bridge out of service? > > > > > > > > > >=20 > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement:=20 > Repeat times=20 > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > Hisham, > > > > > > > > > > >=20 > > > > > > > > > > > The conference server is not mentioned in > > > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > > > > framework=20 > > > > > > > > > > > mentioned the > > > > > > > > > > > conference policy server. As for reservation my=20 > > > > > > view is that=20 > > > > > > > > > > > reservation is > > > > > > > > > > > starting an ad-hoc conference when the schedule=20 > > > > time has=20 > > > > > > > > > > > arrived and it > > > > > > > > > > > should not be part of the conference policy.=20 > > > > > Reservation is=20 > > > > > > > > > > a separate > > > > > > > > > > > application from the conference policy. I=20 > > > > suggest that if=20 > > > > > > > > > > you want to > > > > > > > > > > > address it then we should have a separate=20 > > > > element in the=20 > > > > > > > > > > > frame work which > > > > > > > > > > > will be a reservation server. > > > > > > > > > > >=20 > > > > > > > > > > > Roni > > > > > > > > > > >=20 > > > > > > > > > > > ************************************* > > > > > > > > > > > Roni Even > > > > > > > > > > >=20 > > > > > > > > > > > Polycom Israel > > > > > > > > > > >=20 > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > > > ******************************************* > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > > > To: roni.even@polycom.co.il;=20 > > > > petri.koskelainen@nokia.com;=20 > > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement:=20 > Repeat times=20 > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > No, the focus host (conference server) is the=20 > > > one that=20 > > > > > > > > handles the > > > > > > > > > > > reservations. The focus is only created and=20 > > > > > > destroyed by the=20 > > > > > > > > > > > conference > > > > > > > > > > > server according to the start and stop times. > > > > > > > > > > >=20 > > > > > > > > > > > /Hisham > > > > > > > > > > >=20 > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Even, Roni=20 > > > [mailto:roni.even@polycom.co.il] > > > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > > > > Even, Roni;=20 > > > > > > > > > > > > Khartabil Hisham > > > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement:=20 > > Repeat times=20 > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > Hi Petri, > > > > > > > > > > > > The CPS is a data storage that is used by the=20 > > > > > > focus, so the=20 > > > > > > > > > > > > focus will have > > > > > > > > > > > > to handle the reservation > > > > > > > > > > > > Roni > > > > > > > > > > > >=20 > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > > > To: roni.even@polycom.co.il;=20 > > > > > hisham.khartabil@nokia.com;=20 > > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement:=20 > > Repeat times=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > >=20 > > > > > > > > > > > > > My opinion is that the conference policy=20 > > > > needs only a=20 > > > > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > > > > application to the focus. According to the=20 > > > > conference=20 > > > > > > > > > > > > > framework the focus is using the=20 > > > information in the=20 > > > > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > > > > not the right place for reservation. > > > > > > > > > > > >=20 > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > > > I think it makes sense to have this=20 > (repeat time)=20 > > > > > > > capability in protocol since we need the feature=20 > anyway in=20 > > > > > > real-world=20 > > > > > > > (either in CPCP or in some new mystery protocol=20 > between the=20 > > > > > > user and the=20 > > > > > > > > > > reservation application). > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > -- > > > > > > > > > > > > Petri > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > > Regards > > > > > > > > > > > > > Roni Even > > > > > > > > > > > > >=20 > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > A conference has start and stop times.=20 > > Although the=20 > > > > > > > > > > current proposed solution has repeat times (eg:=20 > > > > > > meeting repeats > > > > > > weekly),=20 > > > > > > > > > > there is no requirement for such. > > > > > > > > > > > >=20 > > > > > > > > > > > > Do we see a need for such capability=20 > > using CPCP? If=20 > > > > > > > so, then we need to add a requirement. > > > > > >=20 > > > > > > _______________________________________________ > > > > > > XCON mailing list > > > > > > XCON@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > >=20 > > > > > > _______________________________________________ > > > > > > XCON mailing list > > > > > > XCON@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Jan 29 12:26:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02841 for ; Thu, 29 Jan 2004 12:26:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFvu-0006im-5h for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 12:26:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THQQNm025836 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 12:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFvt-0006ib-OU for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 12:26:25 -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 MAA02741 for ; Thu, 29 Jan 2004 12:26:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmFvs-00049o-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 12:26:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmFuO-0003rR-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 12:24:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmFte-0003gZ-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 12:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFte-0005NO-In; Thu, 29 Jan 2004 12:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEt3-0002Gt-A1 for xcon@optimus.ietf.org; Thu, 29 Jan 2004 11:19:25 -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 LAA29445 for ; Thu, 29 Jan 2004 11:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEt2-0003rW-00 for xcon@ietf.org; Thu, 29 Jan 2004 11:19:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEs7-0003l0-00 for xcon@ietf.org; Thu, 29 Jan 2004 11:18:29 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AmErB-0003Y4-00 for xcon@ietf.org; Thu, 29 Jan 2004 11:17:29 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 20403; Thu, 29 Jan 2004 11:18:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 29 Jan 2004 11:16:55 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A0CF@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPkCiwg9yPfTyRES/SIjdRtVeO4hgADmaUgAJqQ8IA= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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: quoted-printable Content-Transfer-Encoding: quoted-printable iCal isn't just an example of complexity, but an example of something = that exists. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, January 26, 2004 9:34 AM > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I believe there has been more voices for having scheduling=20 > information in a conference policy than not. The issue was=20 > how complex do we make it. >=20 > iCal was introduced in the discussion as an indicator of how=20 > complex it can be. >=20 > Perhaps I'm missing your point. What was the reason for your=20 > objection again? >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 26.January.2004 14:45 > > To: Khartabil Hisham (Nokia-TP/Helsinki); Even, Roni;=20 > > Koskelainen Petri > > (Nokia-NRC/Tampere); xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Hisham, > > I can not understand why you conclude that there is a rough=20 > > consensus. I > > looked at this thread and there are mixed views. > > I would like to add that considering another protocol like=20 > > iCal points again > > to show that this is a different application.=20 > > I can agree to conference duration but I would recommend not=20 > > to get into > > future reservations > > 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: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, January 26, 2004 1:43 PM > > To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;=20 > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > Roni, > >=20 > > Your objection is noted, but I believe we have rough=20 > > consensus on this issue > > already. The most recent discussions on the list have already=20 > > tapped into > > the solution domain. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Even, Roni > > > Sent: 25.January.2004 15:44 > > > To: Koskelainen Petri (Nokia-NRC/Tampere); xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > Hi, > > > Repeating myself I would like to state my objection, and I=20 > > > would suggest to > > > have conference reservation functionality not in the scope of=20 > > > conference > > > policy but maybe as an application functionality that we may=20 > > > consider as a > > > different working item. > > > Roni > > >=20 > > > ************************************* > > > Roni Even > > >=20 > > > 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=20 > > [mailto:petri.koskelainen@nokia.com] > > > Sent: Sunday, January 25, 2004 3:31 PM > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > >=20 > > > Back to the original question in this thread: > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP?=20 > > > > > > > > > If so, then we need to add a requirement. > > >=20 > > > I guess we can close this open issue now as rough consensus=20 > > seems to=20 > > > be that such a requirement is needed (at least for the=20 > > > start/stop/repeat > > > times). > > > Note that we don't have to design the actual solution yet=20 > > > (e.g. using iCal vs defining own format). > > >=20 > > > -- > > > Petri > > >=20 > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 21.January.2004 16:09 > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > I think we need to figure out where we are going on=20 > scheduling. > > > > >=20 > > > > > First, let me say that I think we SHOULD allow CPCP to at=20 > > > > > least specify start/stop times for conferences, and that if=20 > > > > > the start time is in the future, that is a reservation. > > > >=20 > > > > Agreed. > > > >=20 > > > > >=20 > > > > > What I want to discuss is, how far do we go, and what is=20 > > > > the end game? > > > > > I think we can agree that generalized scheduling is complex,=20 > > > > > and standards exist (iCal). So, the issue I want to=20 > discuss is: > > > > > if we allow simple scheduling (start/stop) now,=20 > > do we EVENTUALLY > > > > > allow complex scheduling? That implies=20 > > duplicating > > > significant > > > > > parts of e.g. iCal. > > > > >=20 > > > > > We could consider an alternative - explicitly support an iCal=20 > > > > > (actually iMIP) transaction now. =20 > > > > >=20 > > > > > One could allow the iMIP Request/Reply only (ie subset of=20 > > > > > iMIP) now (or maybe as a minimum). =20 > > > > >=20 > > > > > Or we could pull in some or all of calsch > > > >=20 > > > > If there is an XML schema already defined that we can use,=20 > > > then it is > > > > possible to embed that in CPCP. If you look at the solution=20 > > > > we are proposing (using XCAP), each feature, like=20 > > > conference-time, has its > > > own=20 > > > > XML namespace. > > > > We can take the iCal XML namespace and just drop it in there. > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > > >=20 > > > > > Brian > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hisham.khartabil@nokia.com=20 > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Yes. > > > > > >=20 > > > > > > We all have weekly meetings with predefined start and stop=20 > > > > > > times. I think it is a valid use case for a user to=20 > create a=20 > > > > > > conference policy to satisfy this once and once only. > > > > > >=20 > > > > > > Regards, > > > > > > Hisham > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);=20 > > > > > > > Koskelainen Petri > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > For that matter, is there a use case for end=20 > points (XCON)=20 > > > > > > > doing such complicated scheduling? Why don't we=20 > just take=20 > > > > > > > the bridge out of service? > > > > > > >=20 > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > >=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hisham, > > > > > > > >=20 > > > > > > > > The conference server is not mentioned in > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The=20 > > framework=20 > > > > > > > > mentioned the > > > > > > > > conference policy server. As for reservation my=20 > > > view is that=20 > > > > > > > > reservation is > > > > > > > > starting an ad-hoc conference when the schedule=20 > time has=20 > > > > > > > > arrived and it > > > > > > > > should not be part of the conference policy.=20 > > Reservation is=20 > > > > > > > a separate > > > > > > > > application from the conference policy. I=20 > suggest that if=20 > > > > > > > you want to > > > > > > > > address it then we should have a separate=20 > element in the=20 > > > > > > > > frame work which > > > > > > > > will be a reservation server. > > > > > > > >=20 > > > > > > > > Roni > > > > > > > >=20 > > > > > > > > ************************************* > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > Polycom Israel > > > > > > > >=20 > > > > > > > > Tel: +972-3-9251200 > > > > > > > > Cell: +972-55-481099 > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > ******************************************* > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > To: roni.even@polycom.co.il;=20 > petri.koskelainen@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > No, the focus host (conference server) is the one that=20 > > > > > handles the > > > > > > > > reservations. The focus is only created and=20 > > > destroyed by the=20 > > > > > > > > conference > > > > > > > > server according to the start and stop times. > > > > > > > >=20 > > > > > > > > /Hisham > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere);=20 > Even, Roni;=20 > > > > > > > > > Khartabil Hisham > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi Petri, > > > > > > > > > The CPS is a data storage that is used by the=20 > > > focus, so the=20 > > > > > > > > > focus will have > > > > > > > > > to handle the reservation > > > > > > > > > Roni > > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > To: roni.even@polycom.co.il;=20 > > hisham.khartabil@nokia.com;=20 > > > > > > > > xcon@ietf.org > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > > > > >=20 > > > > > > > > > Hi Roni, > > > > > > > > >=20 > > > > > > > > > > My opinion is that the conference policy=20 > needs only a=20 > > > > > > > > > > conference duration parameter if any.=20 > > > > > > > > > > I think that reservation is an external=20 > > > > > > > > > > application to the focus. According to the=20 > conference=20 > > > > > > > > > > framework the focus is using the information in the=20 > > > > > > > > > > conference policy server and the focus is=20 > > > > > > > > > > not the right place for reservation. > > > > > > > > >=20 > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > I think it makes sense to have this (repeat time)=20 > > > > capability in protocol since we need the feature anyway in=20 > > > real-world=20 > > > > (either in CPCP or in some new mystery protocol between the=20 > > > user and the=20 > > > > > > > reservation application). > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -- > > > > > > > > > Petri > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > Regards > > > > > > > > > > Roni Even > > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com=20 > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > To: xcon@ietf.org > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > A conference has start and stop times. Although the=20 > > > > > > > current proposed solution has repeat times (eg:=20 > > > meeting repeats > > > weekly),=20 > > > > > > > there is no requirement for such. > > > > > > > > >=20 > > > > > > > > > Do we see a need for such capability using CPCP? If=20 > > > > so, then we need to add a requirement. > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Jan 29 12:46:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04560 for ; Thu, 29 Jan 2004 12:46: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 1AmGEt-0001yT-6Z for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 12:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THk2ug007575 for xcon-archive@odin.ietf.org; Thu, 29 Jan 2004 12:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGEs-0001xu-HH for xcon-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 12:46:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04359 for ; Thu, 29 Jan 2004 12:45:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGEq-0007Ff-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 12:46:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGDL-0006s7-00 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 12:44:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmGBR-0006Oa-04 for xcon-web-archive@ietf.org; Thu, 29 Jan 2004 12:42:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFuT-00066P-9y; Thu, 29 Jan 2004 12:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFgO-0004qQ-NL for xcon@optimus.ietf.org; Thu, 29 Jan 2004 12:10:24 -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 MAA01894 for ; Thu, 29 Jan 2004 12:10:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmFgN-00024e-00 for xcon@ietf.org; Thu, 29 Jan 2004 12:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmFfP-0001yR-00 for xcon@ietf.org; Thu, 29 Jan 2004 12:09:25 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx with esmtp (Exim 4.12) id 1AmFeT-0001mS-00 for xcon@ietf.org; Thu, 29 Jan 2004 12:08:25 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HS9001E7G54QB@firewall.mci.com> for xcon@ietf.org; Thu, 29 Jan 2004 16:51:04 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HS900701G53TK@pmismtp02.mcilink.com>; Thu, 29 Jan 2004 16:51:04 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.152.6]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HS90072CG51QF@pmismtp02.mcilink.com>; Thu, 29 Jan 2004 16:51:03 +0000 (GMT) Date: Thu, 29 Jan 2004 10:50:49 -0600 From: Alan Johnston Subject: RE: [XCON] CPCP Requirement: Repeat times In-reply-to: <4A3384433CE2AB46A63468CB207E209DB1A0CB@zoe.office.snowshor e.com> X-Sender: Alan.Johnston@pop.mcit.com To: Eric Burger , "Rosen, Brian" , xcon@ietf.org Message-id: <5.2.1.1.0.20040129104849.01cb9f08@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed 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 Sounds like we are headed towards consensus on this. The requirement for having a start time (in the future) is so that a conference URI can be reserved in advance. The reservation of actual resources is way, way beyond XCON's charter. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 10:56 AM 1/29/2004 -0500, Eric Burger wrote: >If the start time is not in the future, it makes for a pretty useless >service :-) > >I can go for that. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, January 29, 2004 10:48 AM > > To: Eric Burger; hisham.khartabil@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Do we all agree that the start time can be in the future, and that > > constitutes a (simple) reservation? > > > > I am also okay with no repeats. > > > > Brian > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Thursday, January 29, 2004 10:42 AM > > > To: hisham.khartabil@nokia.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Exactly. The idea "we'll start small and extend later" on > > > the reservation / scheduling function is how we will end up > > > re-inventing iCal, only this time with people with less > > > expertise in the area... > > > > > > I think all we need is start time & end time. Period. > > > > > > > -----Original Message----- > > > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com] > > > > Sent: Wednesday, January 28, 2004 9:39 AM > > > > To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > > > > Cc: roni.even@polycom.co.il > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > If a conference focus is created at conference start time by > > > > a conference factory, the focus will only need to know it's > > > > end time in order to prevent any users from joining. > > > > Repeat times and more complex reservations can be handled by > > > > an "external" reservation > > > > application. > > > > > > > > Dave Boyer > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of > > > > hisham.khartabil@nokia.com > > > > Sent: Wednesday, January 28, 2004 6:50 AM > > > > To: eburger@snowshore.com; xcon@ietf.org > > > > Cc: roni.even@polycom.co.il > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Let me elaborate a little on this proposal. > > > > > > > > I agree that eventually we need complex scheduling for > > > > conferences. We can pick this up after we finalise a solution > > > > for CPCP. In can be decided at that point if this scheduling > > > > could be done inside CPCP as an extension (similar approach > > > > to CPL) or is a separate protocol. > > > > > > > > In the mean time, we can define a very simple start, stop and > > > > repeat times that is OPTIONAL TO IMPLEMENT at the client > > > > side. The purpose of those would not be to indicate the need > > > > for resource reservation, although they can be used for that. > > > > > > > > Start time indicates to the focus when it should start > > > > allowing users to join or when it should invite users to join. > > > > Stop time indicates to the focus when it should stop allowing > > > > users to join. It also indicates that the focus should not > > > > invite users that have been added to dial-out list. > > > > Repeat times is obvious. > > > > > > > > Again, this would be optional and can be deprecated by a more > > > > complex scheduling solution. > > > > > > > > Regards, > > > > Hisham > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > hisham.khartabil@nokia.com > > > > > Sent: 28.January.2004 09:30 > > > > > To: eburger@snowshore.com; xcon@ietf.org > > > > > Cc: roni.even@polycom.co.il > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > I'm sorry, but I don't buy the argument that just because > > > > > scheduling is complex it requires a separate protocol. > > > > > Henning did mention how they approached the problem for CPL. > > > > > We can adopt that here also. > > > > > > > > > > If we don't want a full scheduling solution yet, then we > > > > > start with something basic and design the protocol in a way > > > > > that allows complex scheduling to be added later. > > > > > > > > > > /Hisham > > > > > > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > > Behalf Of ext > > > > > > Eric Burger > > > > > > Sent: 26.January.2004 21:23 > > > > > > To: xcon@ietf.org > > > > > > Cc: Even, Roni > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > I started to say that it was totally out of scope. Here are > > > > > > both sides of the coin: > > > > > > > > > > > > AGAINST *ANY* SCHEDULING IN CPCP: > > > > > > Scheduling logic is arbitrarily complex. Scheduling > > > > > > semantics are arbitrarily complex, and have been tackled in > > > > > > other venues much better than we every will (e.g., iCal). > > > > > > What more does CPCP need other than "Create conference NOW" > > > > > > and "Remove conference NOW"? > > > > > > > > > > > > FOR *SOME* SCHEDULING IN CPCP: > > > > > > Resource management should be at the focus, not at the > > > > > > application. This would lead to "Reserve resources for a > > > > > > conference starting LATER" (could succeed or fail). > > > > > > > > > > > > I *might* understand "Reserve resources for a conference that > > > > > > repeats every {time unit}". > > > > > > > > > > > > I would NOT approve "Reserve resources for a conference that > > > > > > repeats every week except for the week after next." Limit > > > > > > ourselves to "Reserve resources for a conference this week > > > > > > and next. + Reserve resources for a conference starting > > > > > > three weeks from now." > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > Sent: Sunday, January 25, 2004 8:44 AM > > > > > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > Repeating myself I would like to state my objection, and I > > > > > > > would suggest to > > > > > > > have conference reservation functionality not in > > the scope of > > > > > > > conference > > > > > > > policy but maybe as an application functionality > > that we may > > > > > > > consider as a > > > > > > > different working item. > > > > > > > Roni > > > > > > > > > > > > > > ************************************* > > > > > > > Roni Even > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > Cell: +972-55-481099 > > > > > > > email:roni.even@polycom.co.il > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: petri.koskelainen@nokia.com > > > > > > [mailto:petri.koskelainen@nokia.com] > > > > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > > > > To: xcon@ietf.org > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > Back to the original question in this thread: > > > > > > > > > > > > > > > > > > > > Do we see a need for such capability > > using CPCP? > > > > > > > > > > > > > If so, then we need to add a requirement. > > > > > > > > > > > > > > I guess we can close this open issue now as rough consensus > > > > > > seems to > > > > > > > be that such a requirement is needed (at least for the > > > > > > > start/stop/repeat > > > > > > > times). > > > > > > > Note that we don't have to design the actual solution yet > > > > > > > (e.g. using iCal vs defining own format). > > > > > > > > > > > > > > -- > > > > > > > Petri > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > > > Sent: 21.January.2004 16:09 > > > > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > I think we need to figure out where we are going on > > > > > scheduling. > > > > > > > > > > > > > > > > > > First, let me say that I think we SHOULD allow > > CPCP to at > > > > > > > > > least specify start/stop times for conferences, > > > and that if > > > > > > > > > the start time is in the future, that is a reservation. > > > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > > > > > > > What I want to discuss is, how far do we go, > > and what is > > > > > > > > the end game? > > > > > > > > > I think we can agree that generalized scheduling is > > > > complex, > > > > > > > > > and standards exist (iCal). So, the issue I want to > > > > > discuss is: > > > > > > > > > if we allow simple scheduling (start/stop) now, > > > > > > do we EVENTUALLY > > > > > > > > > allow complex scheduling? That implies > > > > > > duplicating > > > > > > > significant > > > > > > > > > parts of e.g. iCal. > > > > > > > > > > > > > > > > > > We could consider an alternative - explicitly > > > > support an iCal > > > > > > > > > (actually iMIP) transaction now. > > > > > > > > > > > > > > > > > > One could allow the iMIP Request/Reply only (ie > > subset of > > > > > > > > > iMIP) now (or maybe as a minimum). > > > > > > > > > > > > > > > > > > Or we could pull in some or all of calsch > > > > > > > > > > > > > > > > If there is an XML schema already defined that we > > can use, > > > > > > > then it is > > > > > > > > possible to embed that in CPCP. If you look at > > the solution > > > > > > > > we are proposing (using XCAP), each feature, like > > > > > > > conference-time, has its > > > > > > > own > > > > > > > > XML namespace. > > > > > > > > We can take the iCal XML namespace and just drop it > > > in there. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Hisham > > > > > > > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > > > > We all have weekly meetings with predefined start > > > > and stop > > > > > > > > > > times. I think it is a valid use case for a user to > > > > > create a > > > > > > > > > > conference policy to satisfy this once and once only. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Hisham > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > > > > To: Even, Roni; Khartabil Hisham > > (Nokia-TP/Helsinki); > > > > > > > > > > > Koskelainen Petri > > > > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For that matter, is there a use case for end > > > > > points (XCON) > > > > > > > > > > > doing such complicated scheduling? Why don't we > > > > > just take > > > > > > > > > > > the bridge out of service? > > > > > > > > > > > > > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > > > > > > > > > > > > > The conference server is not mentioned in > > > > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The > > > > > > framework > > > > > > > > > > > > mentioned the > > > > > > > > > > > > conference policy server. As for reservation my > > > > > > > view is that > > > > > > > > > > > > reservation is > > > > > > > > > > > > starting an ad-hoc conference when the schedule > > > > > time has > > > > > > > > > > > > arrived and it > > > > > > > > > > > > should not be part of the conference policy. > > > > > > Reservation is > > > > > > > > > > > a separate > > > > > > > > > > > > application from the conference policy. I > > > > > suggest that if > > > > > > > > > > > you want to > > > > > > > > > > > > address it then we should have a separate > > > > > element in the > > > > > > > > > > > > frame work which > > > > > > > > > > > > will be a reservation server. > > > > > > > > > > > > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > > > > > ************************************* > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > > > > To: roni.even@polycom.co.il; > > > > > petri.koskelainen@nokia.com; > > > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the > > > > one that > > > > > > > > > handles the > > > > > > > > > > > > reservations. The focus is only created and > > > > > > > destroyed by the > > > > > > > > > > > > conference > > > > > > > > > > > > server according to the start and stop times. > > > > > > > > > > > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: ext Even, Roni > > > > [mailto:roni.even@polycom.co.il] > > > > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); > > > > > Even, Roni; > > > > > > > > > > > > > Khartabil Hisham > > > > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > > > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > > > > > > > The CPS is a data storage that is used by the > > > > > > > focus, so the > > > > > > > > > > > > > focus will have > > > > > > > > > > > > > to handle the reservation > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > > > > To: roni.even@polycom.co.il; > > > > > > hisham.khartabil@nokia.com; > > > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > > > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > > > > > > > > > > > > > My opinion is that the conference policy > > > > > needs only a > > > > > > > > > > > > > > conference duration parameter if any. > > > > > > > > > > > > > > I think that reservation is an external > > > > > > > > > > > > > > application to the focus. According to the > > > > > conference > > > > > > > > > > > > > > framework the focus is using the > > > > information in the > > > > > > > > > > > > > > conference policy server and the focus is > > > > > > > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > > > > I think it makes sense to have this > > (repeat time) > > > > > > > > capability in protocol since we need the feature > > anyway in > > > > > > > real-world > > > > > > > > (either in CPCP or in some new mystery protocol > > between the > > > > > > > user and the > > > > > > > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. > > > Although the > > > > > > > > > > > current proposed solution has repeat times (eg: > > > > > > > meeting repeats > > > > > > > weekly), > > > > > > > > > > > there is no requirement for such. > > > > > > > > > > > > > > > > > > > > > > > > > > Do we see a need for such capability > > > using CPCP? If > > > > > > > > so, then we need to add a requirement. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Jan 30 14:03:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09195 for ; Fri, 30 Jan 2004 14:03:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdvO-0005lE-Kl for xcon-archive@odin.ietf.org; Fri, 30 Jan 2004 14:03:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UJ3U35022124 for xcon-archive@odin.ietf.org; Fri, 30 Jan 2004 14:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdvN-0005kL-U4 for xcon-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 14:03:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09168 for ; Fri, 30 Jan 2004 14:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdvL-0005RH-00 for xcon-web-archive@ietf.org; Fri, 30 Jan 2004 14:03:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmduU-0005Gh-00 for xcon-web-archive@ietf.org; Fri, 30 Jan 2004 14:02:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmdtT-0004xj-00 for xcon-web-archive@ietf.org; Fri, 30 Jan 2004 14:01:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdt4-0008VO-Qn; Fri, 30 Jan 2004 14:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdsg-0008Bm-8s for xcon@optimus.ietf.org; Fri, 30 Jan 2004 14:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08922 for ; Fri, 30 Jan 2004 14:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdsd-0004vF-00 for xcon@ietf.org; Fri, 30 Jan 2004 14:00:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amdrj-0004kr-00 for xcon@ietf.org; Fri, 30 Jan 2004 13:59:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Amdqx-0004Ww-00 for xcon@ietf.org; Fri, 30 Jan 2004 13:58:55 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2004 10:58:21 -0800 Received: from SCOTTF-W2K5.cisco.com (dhcp-128-107-141-94.cisco.com [128.107.141.94]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i0UIwElg026042; Fri, 30 Jan 2004 10:58:14 -0800 (PST) Message-Id: <4.3.1.2.20040130110024.02047000@VTG-UM-E2K1> X-Sender: nismail@VTG-UM-E2K1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 30 Jan 2004 11:02:28 -0800 To: "Rosen, Brian" From: Nermeen Ismail Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: "'Eric Burger'" , hisham.khartabil@nokia.com, xcon@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B6355@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , 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 At 10:48 AM 1/29/2004 -0500, Rosen, Brian wrote: >Do we all agree that the start time can be in the future, and that >constitutes a (simple) reservation? > >I am also okay with no repeats. > >Brian If start time can not be in the future then there is no reason for it. I am OK with having a start time. nermeen > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Thursday, January 29, 2004 10:42 AM > > To: hisham.khartabil@nokia.com; xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > Exactly. The idea "we'll start small and extend later" on > > the reservation / scheduling function is how we will end up > > re-inventing iCal, only this time with people with less > > expertise in the area... > > > > I think all we need is start time & end time. Period. > > > > > -----Original Message----- > > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com] > > > Sent: Wednesday, January 28, 2004 9:39 AM > > > To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > > > Cc: roni.even@polycom.co.il > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > If a conference focus is created at conference start time by > > > a conference factory, the focus will only need to know it's > > > end time in order to prevent any users from joining. > > > Repeat times and more complex reservations can be handled by > > > an "external" reservation > > > application. > > > > > > Dave Boyer > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of > > > hisham.khartabil@nokia.com > > > Sent: Wednesday, January 28, 2004 6:50 AM > > > To: eburger@snowshore.com; xcon@ietf.org > > > Cc: roni.even@polycom.co.il > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Let me elaborate a little on this proposal. > > > > > > I agree that eventually we need complex scheduling for > > > conferences. We can pick this up after we finalise a solution > > > for CPCP. In can be decided at that point if this scheduling > > > could be done inside CPCP as an extension (similar approach > > > to CPL) or is a separate protocol. > > > > > > In the mean time, we can define a very simple start, stop and > > > repeat times that is OPTIONAL TO IMPLEMENT at the client > > > side. The purpose of those would not be to indicate the need > > > for resource reservation, although they can be used for that. > > > > > > Start time indicates to the focus when it should start > > > allowing users to join or when it should invite users to join. > > > Stop time indicates to the focus when it should stop allowing > > > users to join. It also indicates that the focus should not > > > invite users that have been added to dial-out list. > > > Repeat times is obvious. > > > > > > Again, this would be optional and can be deprecated by a more > > > complex scheduling solution. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > Behalf Of ext > > > > hisham.khartabil@nokia.com > > > > Sent: 28.January.2004 09:30 > > > > To: eburger@snowshore.com; xcon@ietf.org > > > > Cc: roni.even@polycom.co.il > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > I'm sorry, but I don't buy the argument that just because > > > > scheduling is complex it requires a separate protocol. > > > > Henning did mention how they approached the problem for CPL. > > > > We can adopt that here also. > > > > > > > > If we don't want a full scheduling solution yet, then we > > > > start with something basic and design the protocol in a way > > > > that allows complex scheduling to be added later. > > > > > > > > /Hisham > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > Eric Burger > > > > > Sent: 26.January.2004 21:23 > > > > > To: xcon@ietf.org > > > > > Cc: Even, Roni > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > I started to say that it was totally out of scope. Here are > > > > > both sides of the coin: > > > > > > > > > > AGAINST *ANY* SCHEDULING IN CPCP: > > > > > Scheduling logic is arbitrarily complex. Scheduling > > > > > semantics are arbitrarily complex, and have been tackled in > > > > > other venues much better than we every will (e.g., iCal). > > > > > What more does CPCP need other than "Create conference NOW" > > > > > and "Remove conference NOW"? > > > > > > > > > > FOR *SOME* SCHEDULING IN CPCP: > > > > > Resource management should be at the focus, not at the > > > > > application. This would lead to "Reserve resources for a > > > > > conference starting LATER" (could succeed or fail). > > > > > > > > > > I *might* understand "Reserve resources for a conference that > > > > > repeats every {time unit}". > > > > > > > > > > I would NOT approve "Reserve resources for a conference that > > > > > repeats every week except for the week after next." Limit > > > > > ourselves to "Reserve resources for a conference this week > > > > > and next. + Reserve resources for a conference starting > > > > > three weeks from now." > > > > > > > > > > > -----Original Message----- > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > Sent: Sunday, January 25, 2004 8:44 AM > > > > > > To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > Hi, > > > > > > Repeating myself I would like to state my objection, and I > > > > > > would suggest to > > > > > > have conference reservation functionality not in the scope of > > > > > > conference > > > > > > policy but maybe as an application functionality that we may > > > > > > consider as a > > > > > > different working item. > > > > > > Roni > > > > > > > > > > > > ************************************* > > > > > > Roni Even > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > Cell: +972-55-481099 > > > > > > email:roni.even@polycom.co.il > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: petri.koskelainen@nokia.com > > > > > [mailto:petri.koskelainen@nokia.com] > > > > > > Sent: Sunday, January 25, 2004 3:31 PM > > > > > > To: xcon@ietf.org > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > Back to the original question in this thread: > > > > > > > > > > > > > > > > > > Do we see a need for such capability using CPCP? > > > > > > > > > > > > If so, then we need to add a requirement. > > > > > > > > > > > > I guess we can close this open issue now as rough consensus > > > > > seems to > > > > > > be that such a requirement is needed (at least for the > > > > > > start/stop/repeat > > > > > > times). > > > > > > Note that we don't have to design the actual solution yet > > > > > > (e.g. using iCal vs defining own format). > > > > > > > > > > > > -- > > > > > > Petri > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > > Sent: 21.January.2004 16:09 > > > > > > > > To: Khartabil Hisham (Nokia-TP/Helsinki) > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > I think we need to figure out where we are going on > > > > scheduling. > > > > > > > > > > > > > > > > First, let me say that I think we SHOULD allow CPCP to at > > > > > > > > least specify start/stop times for conferences, > > and that if > > > > > > > > the start time is in the future, that is a reservation. > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > > > > What I want to discuss is, how far do we go, and what is > > > > > > > the end game? > > > > > > > > I think we can agree that generalized scheduling is > > > complex, > > > > > > > > and standards exist (iCal). So, the issue I want to > > > > discuss is: > > > > > > > > if we allow simple scheduling (start/stop) now, > > > > > do we EVENTUALLY > > > > > > > > allow complex scheduling? That implies > > > > > duplicating > > > > > > significant > > > > > > > > parts of e.g. iCal. > > > > > > > > > > > > > > > > We could consider an alternative - explicitly > > > support an iCal > > > > > > > > (actually iMIP) transaction now. > > > > > > > > > > > > > > > > One could allow the iMIP Request/Reply only (ie subset of > > > > > > > > iMIP) now (or maybe as a minimum). > > > > > > > > > > > > > > > > Or we could pull in some or all of calsch > > > > > > > > > > > > > > If there is an XML schema already defined that we can use, > > > > > > then it is > > > > > > > possible to embed that in CPCP. If you look at the solution > > > > > > > we are proposing (using XCAP), each feature, like > > > > > > conference-time, has its > > > > > > own > > > > > > > XML namespace. > > > > > > > We can take the iCal XML namespace and just drop it > > in there. > > > > > > > > > > > > > > Regards, > > > > > > > Hisham > > > > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > Sent: Wednesday, January 21, 2004 8:10 AM > > > > > > > > > To: eburger@snowshore.com; roni.even@polycom.co.il; > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > > We all have weekly meetings with predefined start > > > and stop > > > > > > > > > times. I think it is a valid use case for a user to > > > > create a > > > > > > > > > conference policy to satisfy this once and once only. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Hisham > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > > > > > > > Sent: 20.January.2004 18:01 > > > > > > > > > > To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > > > > > > > > > > Koskelainen Petri > > > > > > > > > > (Nokia-NRC/Tampere); xcon@ietf.org > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For that matter, is there a use case for end > > > > points (XCON) > > > > > > > > > > doing such complicated scheduling? Why don't we > > > > just take > > > > > > > > > > the bridge out of service? > > > > > > > > > > > > > > > > > > > > Wow! Agreeing with Roni twice in one day!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > > > > > > > Sent: Wednesday, January 07, 2004 4:56 AM > > > > > > > > > > > To: 'hisham.khartabil@nokia.com'; Even, Roni; > > > > > > > > > > > petri.koskelainen@nokia.com; xcon@ietf.org > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hisham, > > > > > > > > > > > > > > > > > > > > > > The conference server is not mentioned in > > > > > > > > > > > draft-ietf-sipping-conferencing-framework-01. The > > > > > framework > > > > > > > > > > > mentioned the > > > > > > > > > > > conference policy server. As for reservation my > > > > > > view is that > > > > > > > > > > > reservation is > > > > > > > > > > > starting an ad-hoc conference when the schedule > > > > time has > > > > > > > > > > > arrived and it > > > > > > > > > > > should not be part of the conference policy. > > > > > Reservation is > > > > > > > > > > a separate > > > > > > > > > > > application from the conference policy. I > > > > suggest that if > > > > > > > > > > you want to > > > > > > > > > > > address it then we should have a separate > > > > element in the > > > > > > > > > > > frame work which > > > > > > > > > > > will be a reservation server. > > > > > > > > > > > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > > > ************************************* > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > Polycom Israel > > > > > > > > > > > > > > > > > > > > > > Tel: +972-3-9251200 > > > > > > > > > > > Cell: +972-55-481099 > > > > > > > > > > > email:roni.even@polycom.co.il > > > > > > > > > > > ******************************************* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > Sent: Wednesday, January 07, 2004 11:22 AM > > > > > > > > > > > To: roni.even@polycom.co.il; > > > > petri.koskelainen@nokia.com; > > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, the focus host (conference server) is the > > > one that > > > > > > > > handles the > > > > > > > > > > > reservations. The focus is only created and > > > > > > destroyed by the > > > > > > > > > > > conference > > > > > > > > > > > server according to the start and stop times. > > > > > > > > > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Even, Roni > > > [mailto:roni.even@polycom.co.il] > > > > > > > > > > > > Sent: 06.January.2004 19:06 > > > > > > > > > > > > To: Koskelainen Petri (Nokia-NRC/Tampere); > > > > Even, Roni; > > > > > > > > > > > > Khartabil Hisham > > > > > > > > > > > > (Nokia-TP/Helsinki); 'xcon@ietf.org ' > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Petri, > > > > > > > > > > > > The CPS is a data storage that is used by the > > > > > > focus, so the > > > > > > > > > > > > focus will have > > > > > > > > > > > > to handle the reservation > > > > > > > > > > > > Roni > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: petri.koskelainen@nokia.com > > > > > > > > > > > > To: roni.even@polycom.co.il; > > > > > hisham.khartabil@nokia.com; > > > > > > > > > > > xcon@ietf.org > > > > > > > > > > > > Sent: 06/01/2004 18:50 > > > > > > > > > > > > Subject: RE: [XCON] CPCP Requirement: > > Repeat times > > > > > > > > > > > > > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > > > > > > > > > > > > > My opinion is that the conference policy > > > > needs only a > > > > > > > > > > > > > conference duration parameter if any. > > > > > > > > > > > > > I think that reservation is an external > > > > > > > > > > > > > application to the focus. According to the > > > > conference > > > > > > > > > > > > > framework the focus is using the > > > information in the > > > > > > > > > > > > > conference policy server and the focus is > > > > > > > > > > > > > not the right place for reservation. > > > > > > > > > > > > > > > > > > > > > > > > The reservation is sent to CPS, not to focus. > > > > > > > > > > > > I think it makes sense to have this (repeat time) > > > > > > > capability in protocol since we need the feature anyway in > > > > > > real-world > > > > > > > (either in CPCP or in some new mystery protocol between the > > > > > > user and the > > > > > > > > > > reservation application). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Petri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: hisham.khartabil@nokia.com > > > > > > > > > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > > > > > Sent: Monday, December 15, 2003 4:57 PM > > > > > > > > > > > > To: xcon@ietf.org > > > > > > > > > > > > Subject: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A conference has start and stop times. > > Although the > > > > > > > > > > current proposed solution has repeat times (eg: > > > > > > meeting repeats > > > > > > weekly), > > > > > > > > > > there is no requirement for such. > > > > > > > > > > > > > > > > > > > > > > > > Do we see a need for such capability > > using CPCP? If > > > > > > > so, then we need to add a requirement. > > > > > > > > > > > > _______________________________________________ > > > > > > 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon